Danath
Для решения задачи на дракон-схеме добавляются икона Полка, икона Адрес «Завершение» и икона имя ветки «Завершение».
Оператор Полка обеспечивает:
• прекращение работы данного алгоритма;
• немедленный выход из алгоритма…
При этом надо четко различать:
• фактическую работу алгоритма;
• эргономичное изображение дракон-схемы.
Фактически Полка с надписью «Выход» играет роль конца работы.
Иными словами, маршрут, доходя до полки, ОБРЫВАЕТСЯ.
Происходит выход из алгоритма, но не через икону Конец, а через икону Полка. Полка играет роль конца.
Но с эргономической точки зрения, такие «обрывы» зрительно (только зрительно, не более того) нежелательны.
Нежелательны потому, что у дракон-схемы будет нарисован не один конец, а несколько.
Фактически алгоритм может иметь несколько концов. Неприятность
в том, что глядя на схему, человеку трудно зрительно воспринимать алгоритм, имеющий несколько концов. Такой алгоритм похож на елку, увешанную «концами», как елочными игрушками.
Подобная зрительная сцена распыляет внимание и мешает сосредоточиться на главном.
Поэтому, с эргономической точки зрения, желательно создать видимость того, что у схемы всего один конец. Это нетрудно сделать. Бегунок, двигаясь к концу алгоритма, пробегает через иконы:
• икона Полка с надписью «Выход»;
• икона Адрес «Завершение»;
• икона имя ветки «Завершение»;
• икона Конец.
Возможно, читатель возразит. Дескать, такая схема не отвечает фактическому положению дел и дезориентирует.
С этим возражением нельзя согласиться. На дракон-схеме показано
все, что нужно, для исчерпывающего понимания алгоритма.
Кроме того, соблюдается эргономическое правило: Дракон-схема имеет только один конец.
Редактор при этом не важен, в любой среде придерживаюсь этих правил.
В ДРАКОН-технологии не так. Редактор (точнее ДРАКОН-конструктор) чрезвычайно важен, без него нельзя.
Инструментальная программа ДРАКОН-конструктор содержит специальный математический аппарат, который:
— автоматически рисует соединительные линии между иконами без пересечений, без разрывов и внутренних соединителей;
— сокращает число ошибок.
Похоже, что вы соблюдаете правила ДРАКОНа вручную, это не есть хорошо.
Если хотите попробовать, возьмите программу ИС Дракон Геннадия Тышова
ТЕЗИС АКАДЕМИКА ДОРОДНИЦЫНА
Академик А. А. Дородницын четко проводит границу между алгоритмом и программой, подчеркивая, что «без алгоритмов предмета информатики не существует» [94]. Более того, он предлагает выделить «алгоритмические средства» как отдельную, самостоятельную сущность:
«…состав информатики — это три неразрывно и существенно связанные части: технические средства, программные средства и алгоритмические средства. Если о первых двух частях никогда не забывают — … они получили специальные термины «hardware» и «software», — то алгоритмическая часть информатики остается почему-то в тени… об этой важнейшей части информатики просто забывают» [94].
Таким образом, согласно Дородницыну, алгоритмические средства должны составлять третью, самоценную часть информатики, наряду с программными средствами (software) и техническими средствами (hardware) [94].
Чтобы в полной мере реализовать идею Дородницына, нужно иметь отдельный стандарт, посвященный алгоритмам.
я ни слова не сказал ни в адрес ГОСТа, ни о том, что его следует отменить.
Я вовсе не предлагаю отменить ГОСТ19.701-90.
Я предлагаю:
— сохранить ГОСТ19.701-90 почти полностью;
— убрать из ГОСТ19.701-90 упоминание об алгоритмах;
— создать новый ГОСТ для алгоритмов на основе языка ДРАКОН
Речь шла только о том, что полезность данного подхода не является абсолютом, но сильно зависит от парадигмы программирования, с уклоном на которую создается блок-схема.
Мой ответ состоит из двух пунктов:
1. Хотите, чтобы стандарт сильно зависел от парадигмы программирования? Оченьь хорошо. Пользуйтесь ГОСТ19.701-90. Вы получите блок-схему программы (но не алгоритм).
2. Предлагаемый мною ГОСТ на алгоритмы на основе языка ДРАКОН позволяет создать дракон-схему (блок-схему алгоритма), которая никак не зависит от парадигмы программирования.
Надо развести два понятия: алгоритм и программа. В этом я согласен с академиком Академии наук СССР, основателем Вычислительного центра АН СССР (ВЦ РАН) А.А. Дородницыным.
В чем выигрыш?
Выигрыш, в частности, в том, что мы выходим далеко за рамки программирования и охватываем не только потоки управления, но и алгоритмы действий врача (клинические алгоритмы), биологические процессы, потоки работ (workflows), модели бизнес-процессов и т. д.
Я согласен с вами. Язык ДРАКОН не позволяет исключить все ошибки.
Статистика на этот счет отсутствует.
Дело осложняется тем, что ДРАКОН мало кому известен и занимает ничтожную (почти нулевую) долю рынка.
Как же в таком случае можно оценить реальное положение вещей (feedback)?
Приходится полагаться на три источника:
— специалисты, которые реально используют ДРАКОН и которых я знаю и которым доверяю (их немного);
— сообщения в сети интернет об использовании языка ДРАКОН;
— отзывы в печати.
Я процитировал два отзыва из сети.
Слова Романа Озерова вызвали здесь сомнения. Я не знаком с Романом и не знаю подробностей (кроме того текста, что я процитировал).
Приведу слова Сергея Ефанова, которого хорошо знаю:
Использую ДРАКОН уже десять лет (с 2010 года) при программировании микроконтроллеров: PIC (Microchip), MSP430 (Texas Instruments), STM32 (STMicroelectronics).
За это время с помощью программы ИС Дракон я сделал несколько десятков проектов: торговые автоматы, блоки защиты электродвигателей, GPS-трекеры, GSM-устройства и др.
Когда пришлось столкнуться с незнакомой ранее темой торговли, управления контрольно-кассовыми машинами — ДРАКОН просто спас. Без него я бы, наверное, не смог быстро привести сеть торговых автоматов в соответствие с новым федеральным законом «54-Ф3».
Прекращать, или сокращать каким-либо образом применение ДРАКОНа не планирую.
Rsa97
Вы правы. Это действительно конечный автомат, который можно реализовать практически на любом языке.
Но. В языке ДРАКОН это единая алгоритмическая макроконструкция, а этого нет ни в одном визуальном языке (и в текстовых тоже).
Добавлю. В ДРАКОН-конструкторе ИС Дракон Геннадия Тышова предусмотрены три режима работы с силуэтом.
— Процедурный
— Автомат 1
— Автомат 2
Два последних — это режимы автоматного программирования
Одна из целей ДРАКОНа — сократить число ошибок. ДРАКОН устраняет не все, но многие ошибки.
Вот отзывы из сети:
«Язык Дракон — это способ визуального описания алгоритмов, исключающий ошибки» (vtral).
«Я на ДРАКОНе работаю уже шесть лет. Любое создание программы начинаю с него и при отладке работаю только с ним. Скорость разработки, качество возрастает в разы! ДРАКОН — это сила, но многие не догоняют, думают, что это обычная блок-схема» (Ро-
ман Озеров).
goto опасен хоть написанный руками, хоть сгенерированный автоматически, если он ведёт туда, куда нельзя.
Если сгенерированный автоматически goto или jmp ведёт туда, куда нельзя, значит компилятор (транслятор, конвертер) содержит ошибку; его надо доработать. Только и всего.
то, что сейчас нарисовано справа, не сделать без goto, так как из Б есть переход, ведущий внутрь ветки ГЕЖИ.
То есть, преобразовать эту схему в структурную программу напрямую не получится.
Структурное программирование создано для текстового (textual) одномерного программирования.
Язык ДРАКОН подчиняется правилам визуального (visual) двумерного структурного программирования см здесь
насчет goto
goto опасен, когда его пишут руками.
goto не опасен, когда он формируется автоматически (как и jump).
В дракон-схемах нет goto. В ДРАКОНе никто не пишет goto руками.
Он (goto) появляется автоматически при конвертации дракон-схемы в исходный код выбранного целевого языка. Но на этот исходный код не надо смотреть, как мы не смотрим на машинный код после компиляции.
Это правило шампура напоминает правило старинного бейсика — нумеровать строки через 10. В конце 20 века на нумерацию строк уже забили, ибо текстовые редакторы научились управлять строками кода без явной нумерации.
Вы правы, текстовые редакторы научились управлять строками кода без явной нумерации.
Но к языку ДРАКОН это не имеет ни малейшего отношения.
Дракон-схему рисуют с помощью специальных инструментальных программ ДРАКОН-редактор.
Сейчас существуют три ДРАКОН-редактора.
Попробуйте их. Ни один ДРАКОН-редактор не позволит вам нарисовать схему с пересечениями.
ДРАКОН-редакторы реализуют визуальное логическое исчисление (исчисление икон). Любая дракон-схема выводится из визуальной аксиомы методом визуального логического вывода. Это специальный математический аппарат (визуальная математическая логика).
если нельзя, но очень хочется, то немножечко можно. Так?
Нет, не так.
Совсем не так.
Вы видите дракон-схему Силуэт. Это основная и наиболее мощная конструкция языка ДРАКОН.
Силуэт состоит из веток. Ветка — зрительно-смысловая часть алгоритма. Порядок выполнения веток указан в иконах Адрес.
На чертеже вы видите силуэт из пяти веток.
Каждая ветка имеет свой шампур.
На данном чертеже Вы видите пять шампуров.
Я рекомендую рисовать шампуры жирной линией.
Но автор этого ДРАКОН-конструктора не выполнил эту рекомендацию. И нарисовал шамруры обычной линией (а не жирной).
Все пять шампуров на этом чертеже нарисованы правильно.
Надо лишь сделать их жирными.
Владимир Данилович, а есть ли возможность фигуры из вашей нотации (те, что на иллюстрациях) выложить в любом векторном формате, а еще лучше — в виде библиотеки для ......................
Вся информация в моих книгах и статьях полностью открыта. Вы можете использовать ее по своему усмотрению полностью или частично.
Но. Фигуры — только часть дела. Чрезвычайно важно, чтобы были правильные связи между иконами, то есть соединительные линии, причем без пересечений и внутренних соединителей.
В ДРАКОНе связи строго формализованы с помощью визуального аксиоматического метода (метод визуального логического исчисления). Благодаря логико-математической формализации достигается защита от многих (но не всех) ошибок. Защита от ошибок — важная часть идеологии ДРАКОНа.
Используя только фигуры и отбрасывая защищенные связи между фигурами, вы выбрасываете автоматическую защиту от ошибок, которую реализует правильно построенный ДРАКОН-конструктор.
Отзыв индивидуального предпринимателя Сергея Ефанова о языке ДРАКОН
Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
Функция заработала сразу!
Более того, при переносе алгоритма в дракон-схему, я обнаружил, что у меня в ней была ошибка! Эта функция работала уже довольно давно, не в одной сотне изделий. Ошибка не была фатальной, она возникала редко, и компенсировалась переподключением к серверу. Но она была!
Я в качестве эксперимента делаю что-то вроде визуальной фронтенд-студии и попробовал реализовать дракон в качестве основного языка визуального программирования (не гибридный ДРАКОН-JavaScript, а чистый Дракон со специальным движком обработки данных, похожим на смесь Excel и Smalltalk).
Я приветствую вашу инициативу и ваш эксперимент. И желаю вам успехов.
Ваш текст я выложил на форуме языка ДРАКОН здесь.
Приглашаю вас принять участие в работе форума и рассказать о ходе вашей интересной разработки.
Стандарт ГОСТ 19.701—90 — это действующий стандарт.
Он используется при выпуске документации прежде всего. Речь идет о схемах алгоритмов. Этот стандарт задает графику схем алгоитмов. Но не коды. Коды здесь вообще ни при чем.
Вы, по-видимому, не используете стандарт ГОСТ 19.701—90.
Но другие разработчики вынуждены им пользоваться.
К сожалению, ваш комментарий не относится к теме статьи.
Отвечаю по поводу кодов
В моей статье в разделе Литература указано:
11. (2017) Митькин С.Б. Визуальное программирование на языке ДРАКОН. — Хабр, 2017 ( rykkinn )
Степан Митькин rykkinn — автор трех ДРАКОН-конструкторов (Норвегия) три с лишним года назад опубликовал на Хабре длинный пост Визуальное программирование на языке ДРАКОН, содержащий большое количество примеров на гибридном языке Дракон-JavaScript c кодами. Я исходил из того, что за прошедшие три года все желающие посмотрели статью Митькина и получили подробные ответы насчет кодов.
Если это не так, ничего страшного. Можно посмотреть статью Митькина и сейчас. Вот ссылка.
Предлагаю вам тему диссертации: «Визуальная математическая логика как теоретическая основа визуального алгоритмичческого языка ДРАКОН».
Это новое научное направление, диссертация в ученом совете пройдет на ура. Если вам это интересно, я составлю для вас план диссертации.
Защищаться вам можно, например: — в Институте системного программирования Российской академии наук;
— или на кафедре системного программирования матмеха Санкт-Петербургского университета.
Если хотите, я переговорю с руководителями. Подумайте.
Это не так. Наоборот, ДРАКОН устраняет путаницу и облегчает понимание алгоритма. Для этого он и создан.
Особенно большую пользу ДРАКОН приносит непрограммистам, программистам-любителям, начинающим программистам.
Посмотрите статью Сергея Ефанова. Возможно, она внесет ясность.
Для решения задачи на дракон-схеме добавляются икона Полка, икона Адрес «Завершение» и икона имя ветки «Завершение».
Оператор Полка обеспечивает:
• прекращение работы данного алгоритма;
• немедленный выход из алгоритма…
При этом надо четко различать:
• фактическую работу алгоритма;
• эргономичное изображение дракон-схемы.
Фактически Полка с надписью «Выход» играет роль конца работы.
Иными словами, маршрут, доходя до полки, ОБРЫВАЕТСЯ.
Происходит выход из алгоритма, но не через икону Конец, а через икону Полка. Полка играет роль конца.
Но с эргономической точки зрения, такие «обрывы» зрительно (только зрительно, не более того) нежелательны.
Нежелательны потому, что у дракон-схемы будет нарисован не один конец, а несколько.
Фактически алгоритм может иметь несколько концов. Неприятность
в том, что глядя на схему, человеку трудно зрительно воспринимать алгоритм, имеющий несколько концов. Такой алгоритм похож на елку, увешанную «концами», как елочными игрушками.
Подобная зрительная сцена распыляет внимание и мешает сосредоточиться на главном.
Поэтому, с эргономической точки зрения, желательно создать видимость того, что у схемы всего один конец. Это нетрудно сделать. Бегунок, двигаясь к концу алгоритма, пробегает через иконы:
• икона Полка с надписью «Выход»;
• икона Адрес «Завершение»;
• икона имя ветки «Завершение»;
• икона Конец.
Возможно, читатель возразит. Дескать, такая схема не отвечает фактическому положению дел и дезориентирует.
С этим возражением нельзя согласиться. На дракон-схеме показано
все, что нужно, для исчерпывающего понимания алгоритма.
Кроме того, соблюдается эргономическое правило: Дракон-схема имеет только один конец.
В ДРАКОН-технологии не так. Редактор (точнее ДРАКОН-конструктор) чрезвычайно важен, без него нельзя.
Инструментальная программа ДРАКОН-конструктор содержит специальный математический аппарат, который:
— автоматически рисует соединительные линии между иконами без пересечений, без разрывов и внутренних соединителей;
— сокращает число ошибок.
Похоже, что вы соблюдаете правила ДРАКОНа вручную, это не есть хорошо.
Если хотите попробовать, возьмите программу ИС Дракон Геннадия Тышова
Продолжение ответа
ТЕЗИС АКАДЕМИКА ДОРОДНИЦЫНА
Академик А. А. Дородницын четко проводит границу между алгоритмом и программой, подчеркивая, что «без алгоритмов предмета информатики не существует» [94]. Более того, он предлагает выделить «алгоритмические средства» как отдельную, самостоятельную сущность:
Таким образом, согласно Дородницыну, алгоритмические средства должны составлять третью, самоценную часть информатики, наряду с программными средствами (software) и техническими средствами (hardware) [94].
Чтобы в полной мере реализовать идею Дородницына, нужно иметь отдельный стандарт, посвященный алгоритмам.
Я вовсе не предлагаю отменить ГОСТ19.701-90.
Я предлагаю:
— сохранить ГОСТ19.701-90 почти полностью;
— убрать из ГОСТ19.701-90 упоминание об алгоритмах;
— создать новый ГОСТ для алгоритмов на основе языка ДРАКОН
Мой ответ состоит из двух пунктов:
1. Хотите, чтобы стандарт сильно зависел от парадигмы программирования? Оченьь хорошо. Пользуйтесь ГОСТ19.701-90. Вы получите блок-схему программы (но не алгоритм).
2. Предлагаемый мною ГОСТ на алгоритмы на основе языка ДРАКОН позволяет создать дракон-схему (блок-схему алгоритма), которая никак не зависит от парадигмы программирования.
Надо развести два понятия: алгоритм и программа. В этом я согласен с академиком Академии наук СССР, основателем Вычислительного центра АН СССР (ВЦ РАН) А.А. Дородницыным.
В чем выигрыш?
Выигрыш, в частности, в том, что мы выходим далеко за рамки программирования и охватываем не только потоки управления, но и алгоритмы действий врача (клинические алгоритмы), биологические процессы, потоки работ (workflows), модели бизнес-процессов и т. д.
Я согласен с вами. Язык ДРАКОН не позволяет исключить все ошибки.
Статистика на этот счет отсутствует.
Дело осложняется тем, что ДРАКОН мало кому известен и занимает ничтожную (почти нулевую) долю рынка.
Как же в таком случае можно оценить реальное положение вещей (feedback)?
Приходится полагаться на три источника:
— специалисты, которые реально используют ДРАКОН и которых я знаю и которым доверяю (их немного);
— сообщения в сети интернет об использовании языка ДРАКОН;
— отзывы в печати.
Я процитировал два отзыва из сети.
Слова Романа Озерова вызвали здесь сомнения. Я не знаком с Романом и не знаю подробностей (кроме того текста, что я процитировал).
Приведу слова Сергея Ефанова, которого хорошо знаю:
Вы правы. Это действительно конечный автомат, который можно реализовать практически на любом языке.
Но. В языке ДРАКОН это единая алгоритмическая макроконструкция, а этого нет ни в одном визуальном языке (и в текстовых тоже).
Добавлю. В ДРАКОН-конструкторе ИС Дракон Геннадия Тышова предусмотрены три режима работы с силуэтом.
— Процедурный
— Автомат 1
— Автомат 2
Два последних — это режимы автоматного программирования
Вот отзывы из сети:
Если в дракон-схеме Примитив нельзя сделать без пересечений, надо использовать дракон-схему Силуэт.
Силуэт позволяет убрать любые пересечения.
Алгоритмическая макроконструкция Силуэт не имеет аналогов в других языках.
Если сгенерированный автоматически goto или jmp ведёт туда, куда нельзя, значит компилятор (транслятор, конвертер) содержит ошибку; его надо доработать. Только и всего.
Структурное программирование создано для текстового (textual) одномерного программирования.
Язык ДРАКОН подчиняется правилам визуального (visual) двумерного структурного программирования см здесь
насчет goto
goto опасен, когда его пишут руками.
goto не опасен, когда он формируется автоматически (как и jump).
В дракон-схемах нет goto. В ДРАКОНе никто не пишет goto руками.
Он (goto) появляется автоматически при конвертации дракон-схемы в исходный код выбранного целевого языка. Но на этот исходный код не надо смотреть, как мы не смотрим на машинный код после компиляции.
Вы правы, текстовые редакторы научились управлять строками кода без явной нумерации.
Но к языку ДРАКОН это не имеет ни малейшего отношения.
Дракон-схему рисуют с помощью специальных инструментальных программ ДРАКОН-редактор.
Сейчас существуют три ДРАКОН-редактора.
Попробуйте их. Ни один ДРАКОН-редактор не позволит вам нарисовать схему с пересечениями.
ДРАКОН-редакторы реализуют визуальное логическое исчисление (исчисление икон). Любая дракон-схема выводится из визуальной аксиомы методом визуального логического вывода. Это специальный математический аппарат (визуальная математическая логика).
Нет, не так.
Совсем не так.
Вы видите дракон-схему Силуэт. Это основная и наиболее мощная конструкция языка ДРАКОН.
Силуэт состоит из веток. Ветка — зрительно-смысловая часть алгоритма. Порядок выполнения веток указан в иконах Адрес.
На чертеже вы видите силуэт из пяти веток.
Каждая ветка имеет свой шампур.
На данном чертеже Вы видите пять шампуров.
Я рекомендую рисовать шампуры жирной линией.
Но автор этого ДРАКОН-конструктора не выполнил эту рекомендацию. И нарисовал шамруры обычной линией (а не жирной).
Все пять шампуров на этом чертеже нарисованы правильно.
Надо лишь сделать их жирными.
Вся информация в моих книгах и статьях полностью открыта. Вы можете использовать ее по своему усмотрению полностью или частично.
Но. Фигуры — только часть дела. Чрезвычайно важно, чтобы были правильные связи между иконами, то есть соединительные линии, причем без пересечений и внутренних соединителей.
В ДРАКОНе связи строго формализованы с помощью визуального аксиоматического метода (метод визуального логического исчисления). Благодаря логико-математической формализации достигается защита от многих (но не всех) ошибок. Защита от ошибок — важная часть идеологии ДРАКОНа.
Используя только фигуры и отбрасывая защищенные связи между фигурами, вы выбрасываете автоматическую защиту от ошибок, которую реализует правильно построенный ДРАКОН-конструктор.
Отзыв индивидуального предпринимателя Сергея Ефанова о языке ДРАКОН
Я приветствую вашу инициативу и ваш эксперимент. И желаю вам успехов.
Ваш текст я выложил на форуме языка ДРАКОН здесь.
Приглашаю вас принять участие в работе форума и рассказать о ходе вашей интересной разработки.
Посмотрите тему
Посмотрите английскую Википедию статья DRAKON.
— Dijkstra search algorithm in DRAKON
— Outer part of quicksort algorithm in DRAKON-C
Посмотрите английскую Википедию статья DRAKON.
— Dijkstra search algorithm in DRAKON
— Outer part of quicksort algorithm in DRAKON-C
Он используется при выпуске документации прежде всего. Речь идет о схемах алгоритмов. Этот стандарт задает графику схем алгоитмов. Но не коды. Коды здесь вообще ни при чем.
Вы, по-видимому, не используете стандарт ГОСТ 19.701—90.
Но другие разработчики вынуждены им пользоваться.
К сожалению, ваш комментарий не относится к теме статьи.
В моей статье в разделе Литература указано:
Степан Митькин rykkinn — автор трех ДРАКОН-конструкторов (Норвегия) три с лишним года назад опубликовал на Хабре длинный пост Визуальное программирование на языке ДРАКОН, содержащий большое количество примеров на гибридном языке Дракон-JavaScript c кодами. Я исходил из того, что за прошедшие три года все желающие посмотрели статью Митькина и получили подробные ответы насчет кодов.
Если это не так, ничего страшного. Можно посмотреть статью Митькина и сейчас. Вот ссылка.
Предлагаю вам тему диссертации:
«Визуальная математическая логика как теоретическая основа визуального алгоритмичческого языка ДРАКОН».
Это новое научное направление, диссертация в ученом совете пройдет на ура. Если вам это интересно, я составлю для вас план диссертации.
Защищаться вам можно, например:
— в Институте системного программирования Российской академии наук;
— или на кафедре системного программирования матмеха Санкт-Петербургского университета.
Если хотите, я переговорю с руководителями. Подумайте.