Comments 123
Э… мне одному кажется, что это какая-то тупиковая ветвь развития?
Ну, зато там используются иконы.
Имел опыт с подобным (algorithm builder для avr).
Действительно, сложнее сделать алгоритмическую ошибку. Так что чем выше требуемая надёжность — тем более полезны такие инструменты. Тем более что есть обратный преобразователь (код — диаграмма).
Если нужны мегабайты исходников в день некритичных к качеству — однозначно не нужно.
Действительно, сложнее сделать алгоритмическую ошибку. Так что чем выше требуемая надёжность — тем более полезны такие инструменты. Тем более что есть обратный преобразователь (код — диаграмма).
Если нужны мегабайты исходников в день некритичных к качеству — однозначно не нужно.
Чем выше требования к надежности, тем больше нужно тестов писать. Тесты тоже в этих блок диаграммах?
UFO just landed and posted this here
Почему бы и нет? В статье упоминаются оба подхода.
Диаграмма скорее всего не поместится на экран и ее будет трудно понять.
У меня богатый опыт рассматривания схем для FPGA — графические схемы очень не просто понимать.
У меня богатый опыт рассматривания схем для FPGA — графические схемы очень не просто понимать.
Я не пользовался ДРАКОН, но думаю что логически законченная диаграмма должна помещаться на экран, т.е. сначала программа пишется очень крупными «мазками», дальше каждый крупный блок «уточняется» и т.д. Собственно говоря я и на С так стараюсь писать, но лень-матушка дает о себе знать и бывает довольно лениво объединять код в функцию в 1-10 строк, вызываемую один раз :(
Полагаю, что сравнение схем для FPGA с диаграммами ДРАКОН не совсем корректно, но если заставить себя строго соблюдать правила из ДРАКОН и добавить правило «одного экрана», то будет вполне себе, хотя я схемы для FPGA уже лет 15 не рисовал…
Полагаю, что сравнение схем для FPGA с диаграммами ДРАКОН не совсем корректно, но если заставить себя строго соблюдать правила из ДРАКОН и добавить правило «одного экрана», то будет вполне себе, хотя я схемы для FPGA уже лет 15 не рисовал…
Не, ну как. Для описания простых алгоритмов — положить в печку, ждать 15 минут, достать, посолить — вполне катит. Когда того, кто создаёт алгоритм о программировании знает только из фантастических фильмов. Когда речь идёт о том, чтобы какой-то реальный софт писать — жуткая жуть, конечно.
Не переживайте. Ветвь развития действительно абсолютно тупиковая. Эта игрушка устарела 25 лет назад. При сегодняшней насыщенности приложений кодом, такой подход добавлет больше гемороя чем пользы. Из визуальных средств разработки полезными являются средства с более высоким уровнем абстракций: UML, BPMN 2.0. С кодогенерацией там тоже проблем нет.
Как ни странно, но люди, не имеющие опыта в программировании, но имеющие потребность что-то запрограммировать (и желательно без привлечения специально обученных людей), любят использовать средства графического программирования. Лет 5 назад был популярен ts lab для биржевого трейдинга, rapidminer более-менее распространенный продукт для обработки данных. Забавляет то, что после нескольких лет использования возникают монстры на 1500 прямоугольников и стрелок, и совладать с таким монстром уже становится сложнее, чем научится писать код
Прямо про zennoposter рассказал. Визуальное программирование для управления браузером. Используется различными маркетологами в интернате, ищущими бесплатный трафик zennolab.com/ru/products/zennoposter
Вот пример простенького шаблона
Я думаю нодовые системы программирования куда читабельнее и практичнее, чем это.
Я правильно понимаю, что это используется исключительно для обучения?
Потому как объемный и сложный код в диаграммах… ну это как-то сложно по моему.
Потому как объемный и сложный код в диаграммах… ну это как-то сложно по моему.
Если судить по тексту, то он летает.
Его основные принципы были заложены ещё самим Дейкстрой. Нынешнюю свою форму ДРАКОН приобрёл в недрах российской космической отрасли. Примечательно то, что правила языка ДРАКОН не возникли случайно. Они были сначала обкатаны в фокус-группах, а потом отточены в реальных космических проектах.
По крайней мере теперь стало ясно почему оно так часто летает не туда и тогда, когда нужно…
А комментарии у минусующих будут? Потому что у всех этих визуальных штучек есть большая проблема: отслеживание истории и зависимостей. Такие вещи, как grep или «git blame» отсутствуют напрочь.
И оп-па: последняя ракета улетает «не туда», потому что кто-то забыл где-то поправить привязку к Байконура. Случайность? Возможно… Но уж очень она характерная…
И оп-па: последняя ракета улетает «не туда», потому что кто-то забыл где-то поправить привязку к Байконура. Случайность? Возможно… Но уж очень она характерная…
Потому что у всех этих визуальных штучек есть большая проблема: отслеживание истории и зависимостей.
С git и grep можно работать и здесь.
Но проблема указана правильно.
С git и grep можно работать и здесь.Меня больше «git blame» интересует. Он для каждой строки указывает — кто и когда её написал. То есть вы, увидев странную проверку в коде, можете сразу посмотреть на тот changelist, который эту проверку добавил. Иногда, конечно, выясняется, что «странная проверка» появилась как результат работы clang-format'а — но тогда можно отступить на шаг и посмотреть на «git blame» уже там.
Главное — нужно просматривать не сотни changelist'ов, а один-два. Очень сильно помогает. Вы говорите, что для ДРАКОНА что-то такое есть. Как оно выглядит и работает-то?
Проблема некоторых программистов, что они видят строки, то есть не очень далеко ушли от кодеров.
Графическое представление алгоритма как раз и нужно для того, что бы наглядно логику алгоритма, то есть более высокий уровень.
Не думаю, что есть готовый инструментарий, но посмотрите на пару-тройку-пятреку-десяток лет назад, сколько было удобный инструментов для JS? Сколько сейчас?
Графическое представление алгоритма как раз и нужно для того, что бы наглядно логику алгоритма, то есть более высокий уровень.
Не думаю, что есть готовый инструментарий, но посмотрите на пару-тройку-пятреку-десяток лет назад, сколько было удобный инструментов для JS? Сколько сейчас?
нет никаких проблем отследивания зависимостей.
Блок-схема (диаграмма итд) — это всего-навсего одно из представлений.
Какие проблемы сделать diff?
Есть же для xml diff, который не тупо строки сравнивает, а структуру документа, точно так же можно и для этого сделать. Если нужно, конечно
Блок-схема (диаграмма итд) — это всего-навсего одно из представлений.
Какие проблемы сделать diff?
Есть же для xml diff, который не тупо строки сравнивает, а структуру документа, точно так же можно и для этого сделать. Если нужно, конечно
Как раз российская космонавтика отправляет что нужно и куда нужно в 99% случаев. Вроде бы хабл не был местом для жополизов-хейтеров, как вы-то тут оказались?
Как раз российская космонавтика отправляет что нужно и куда нужно в 99% случаев.Не в 99% случаев, а, скорее, в 80%. Скажем Протон: 404 запуска, 49 аварий.
Если запускается что-то совершенно новое или радикально изменённое, то это понятно — опыта нет, пока не отработают — аварийность повышена. Как с тем же Фальконом, который взорвался из-за использования экспериментальной процедуры переохлаждения топлива.
У Роскомоса — то что-то неправильно рассчитают, то временной интервал заузят, то скрытую проблему в алгоритме обнаружат.
А ведь все эти рассчёты — это как раз и есть сфера применения суперклассного, высоконадёжного, уникального ДРАКОНа! Или нет?
Вроде бы хабл не был местом для жополизов-хейтеров, как вы-то тут оказались?Не знаю, кто тут хейтёр-жополиз, может быть вы? Если почитаете мои комментарии к статье про Маска, то увидите, что меня вряд ли можно назвать его фанатом.
У него тоже бывают проколы с программами (в той же самой аварии, о которой я уже говорил выше аппарат можно было бы спасти, если бы аппарат был запрограммирован выпускать парашюты при аварии) — но, согласитесь одно дело — не предусмотреть в программе что-то для исключительной ситуации, другое — «пролюбить» «все полимеры» при штатной.
Если ДРАКОН — так удобен и крут, то почему так много ошибок из-за которых происходят аварии, а?
Окай, 80% успешных запусков поротона это собственно по вашему и является основой для хейтеркого по отношению к роскосмосу, который вы тут демонстрировать пытаетесь, прикрываясь горсткой тех. данных и рассуждений якобы по теме. Я вот например не очень понимаю ценности таких вот «оффтопных вставок» еще и невесть на очем осованных, каких делаете вы, отсюда и мой комментарий.
Я вот например не очень понимаю ценности таких вот «оффтопных вставок» еще и невесть на очем осованных, каких делаете вы, отсюда и мой комментарий.Основаны они, вообще-то, на оффициальных данных Роскосмоса.
Я как раз скорее Роскосмос уважаю, однако то, что уж очень много у них «ошибок в алгоритмах» в отчётах я давно для себя отметил.
А тут как раз предлагают их подход к программированию использовать. И сразу возникает вопрос: если хочется экзотики, то, может быть, стоит взять лучше обычный язык программирования (но с более более вменяемым, чем у C#/C++/Java синтаксисом), чем вот это вот чудо?
Ответ простой — дебажить говнокод обычных языков за охренелиард каждую немножко дорого. А ДРАКОН действительно чудо. В рассматриваемой ситуации с неудачным запуском ничего не программировали, хотя надо было. И именно в этом причина. Человеческий фактор.
А ДРАКОН действительно чудо.Тогда почему это «чудо» раз за разом приводит к неправильным вычислениям при запусках?
В рассматриваемой ситуации с неудачным запуском ничего не программировали, хотя надо было.В рассматриваемой — это в какой? Я там наверху три запуска привёл где алгоритмические ошибки привели к проблемам (со слов соответствующей комиссии, по крайней мере).
Человеческий фактор.Но если «говнокод обычных языков» более эффективно позволяет с ним бороться — то, может, так и надо?
Так ДРАКОН сейчас и не используется же?
Там идея исходная такая — инженер своё понимание работы устройства изображает в виде драконовского кода и передаёт программисту. А программист уже пришет собственно код.
А сейчас уже навесили генерацию кода. А я как-то даже написал на яваскрипте самоисполняющийся дракончик. Но из меня программист, как из курицы истребитель, поэтому в общем и целом фигня получилась. Но работала.
А сейчас уже навесили генерацию кода. А я как-то даже написал на яваскрипте самоисполняющийся дракончик. Но из меня программист, как из курицы истребитель, поэтому в общем и целом фигня получилась. Но работала.
Не только, судя по вики
Я пользуюсь. Очень удобно. Поэтому мне лично наплевать, тупиковая это ветвь развития или нет.
Залейте картинки на habrastorage.org
И исправьте SSL у себя на drakon-editor.com
И исправьте SSL у себя на drakon-editor.com
Рисунок 19 доказывает широко-известный факт, что плохой (ненадежный) код можно написать (нарисовать) в любом языке программирования.
Узнал об этом языке от одного участника форума компании, в которой работаю.
Привожу ниже 2 алгоритма.
Один я нарисовал блок-схемами в VISIO,
второй нарисовал он на ДРАКОНе.
Получилось настолько проще, понятнее и элегантнее, что я проникся
Под спойлером обе версии алгоритма для сравнения:
Привожу ниже 2 алгоритма.
Один я нарисовал блок-схемами в VISIO,
второй нарисовал он на ДРАКОНе.
Получилось настолько проще, понятнее и элегантнее, что я проникся
Под спойлером обе версии алгоритма для сравнения:
Обе версии алгоритма
Странно, что слово Scatch не прозвучало.
У меня сыновья с удовольствием развлекаются.
У меня сыновья с удовольствием развлекаются.
Можно было бы написать и про графические инженерные языки (FBD, SFC и.т.п.), которые используются повсеместно (сложно найти объект телемеханики, где бы их не было использовано), в отличие от дракона, стандартизированы, имеют кучу компиляторов и реализаций.
В отличие от дракона большинство программ на FBD или CFC не воспринимаются вообще никак.
Поиск ошибки превращается в ад.
Поиск ошибки превращается в ад.
Дабы не быть голословным
P.S. Мопед не мой, я просто разместил объяву
P.S. Мопед не мой, я просто разместил объяву
Всегда можно вспомнить, что «на фортране можно писать на любом языке» — взять нормальный редактор с подсветкой блоков, использовать функции и функциональные блоки, осмысленные названия переменных, про комментарии не забывать…
Вы не смотрели скриншот?
Подсветка ФБ там не поможет.
Проблема в том, что в этом куске кода слишком много связей внутри, и их тяжело отследить.
От графического языка я, в первую очередь, хочу получить визуализацию связей между частями программы.
Проблему конкретного куска кода из комментария выше можно решить, разбив программу на функции.
Дракон нас вынуждает делать это разбиение и, тем самым, предотвращает появление «хаотичных» связей.
Программа выше разработана на CFC и там нет такого «принуждения». Оно есть в FBD, но там нет возможности запретить выполнение блока. Что вынуждает нас «ломать» мировоззрение и строить программы исходя из этого ограничения.
Подсветка ФБ там не поможет.
Проблема в том, что в этом куске кода слишком много связей внутри, и их тяжело отследить.
От графического языка я, в первую очередь, хочу получить визуализацию связей между частями программы.
Проблему конкретного куска кода из комментария выше можно решить, разбив программу на функции.
Дракон нас вынуждает делать это разбиение и, тем самым, предотвращает появление «хаотичных» связей.
Программа выше разработана на CFC и там нет такого «принуждения». Оно есть в FBD, но там нет возможности запретить выполнение блока. Что вынуждает нас «ломать» мировоззрение и строить программы исходя из этого ограничения.
Ничего страшного в этом куске кода нет. Наверняка его можно причесать, составив булевое выражение между входами и выходами и упростив его. Да даже если не упростится, будет точное соответствие между требуемым мат. описанием и полученным кодом.
Вот для понимания как оно работает, надо узнать назначения входов и выходов.
Ну а теперь призовая задача: вы сделали в программе изменения, отобразите эти изменения графически (что удалено, что вставлено, что изменено). [Подсказка: две диаграммы рядом не размещать]
Задача со звёздочкой: два программиста независимо друг от друга вносят в одну программу изменения (для простоты будем считать, что они делаются в разных местах и не конфликтуют). Слейте эти изменения автоматически в один результат.
Задача со звёздочкой: два программиста независимо друг от друга вносят в одну программу изменения (для простоты будем считать, что они делаются в разных местах и не конфликтуют). Слейте эти изменения автоматически в один результат.
Помните рекламу:
«Вы все еще правите код до того, как внесете изменения на диаграмму классов и алгоритм?
Тогда мы идем к Вам.»?
«Вы все еще правите код до того, как внесете изменения на диаграмму классов и алгоритм?
Тогда мы идем к Вам.»?
По поводу автоматического объединения — не вижу проблемы в том, чтобы отследить изменения в файле с известным форматом.
Вне зависимости от того, что хранится в этом файле: код программы на текстовом языке (выберите любой), код на графическом языке (приведенные выше CFC, FBD или ДРАКОН), рисунок или звуковой файл.
Вне зависимости от того, что хранится в этом файле: код программы на текстовом языке (выберите любой), код на графическом языке (приведенные выше CFC, FBD или ДРАКОН), рисунок или звуковой файл.
Если не видите — покажите. Вот, скажем, на этом примере.
Предположите, что изначально блоков P, C и G не было. Вася добавил блоки P и C, Петя — блок G.
А ваша обьединялка, очевидно, должна породить вот то, что справа — с блоками B1, B2, B3, B4.
Код (на любом языке, не обязательно Драконе) или хотя бы алгоритм — приветствуются.
Предположите, что изначально блоков P, C и G не было. Вася добавил блоки P и C, Петя — блок G.
А ваша обьединялка, очевидно, должна породить вот то, что справа — с блоками B1, B2, B3, B4.
Код (на любом языке, не обязательно Драконе) или хотя бы алгоритм — приветствуются.
Я смотрел на youtube ролики, там человек на ДРАКОНе писал программу для микроконтроллера замка. И ДРАКОН использовался совместно с C. Т.е. структура программы оформлялась на нём, а реализация в блоках (функции из одной-двух строк, работавшие с SDK контроллера) уже на C были. И писались прямо из редактора ДРАКОНа. Ну, а ДРАКОН генерировал финальный исходник на C, конечный автомат и т.д. Так что проблем вроде нет.
С учётом того, что прямо в статье написано:
Собственно одна эта проблема замедляет разработку сложных систем на порядк, а то и на два.
Возможно (возможно — я в этом не на 100% уверен) результат будет более качественным — вот только готов он будет того, когда смысла в нём не будет никакого.
Не все разработчики могут себе позволить такую роскошь — вылизывать код годами, чтобы один и тот же участок кода не правился двумя людьми одновременно.
«Отсутствует инструменты для diff и merge.» Это, к сожалению, так. При работе с системой контроля версий сравнивать приходится сгенерированные исходные файлы.
Собственно одна эта проблема замедляет разработку сложных систем на порядк, а то и на два.
Возможно (возможно — я в этом не на 100% уверен) результат будет более качественным — вот только готов он будет того, когда смысла в нём не будет никакого.
Не все разработчики могут себе позволить такую роскошь — вылизывать код годами, чтобы один и тот же участок кода не правился двумя людьми одновременно.
отобразите эти изменения графически (что удалено, что вставлено, что изменено)
Вы правы, присутствует дефицит таких средств.
Кстати, имеющиеся средства для слияния текстовых программ с трудом справляются, если изменения касаются топологии алгоритма. Отобразить изменения типа CreateWindow -> CreateWindowEx получается хорошо, а переработанный блок вложенных if — не всегда.
Можно подумать над всяким скриптованием простых моделей поведения на этом безобразии для неофитов.
Запрет пересечений принуждает выделять независимые логические блоки, уменьшать цикломатическую сложность:
Круто, когда строим ракету. В «бизнесе» становится недостатком, т.к. не к месту добавленное условие «если луна в Овне — вот это пропускаем, а тут вместо 5 умножаем на 5.3» может заставить переделывать половину программы.
Вообще штука безусловно полезная, но очень нишевая. Для формального описания алгоритмов аля «технологический процесс приготовления борща» подходит идеально :)
Круто, когда строим ракету. В «бизнесе» становится недостатком, т.к. не к месту добавленное условие «если луна в Овне — вот это пропускаем, а тут вместо 5 умножаем на 5.3» может заставить переделывать половину программы.
Вообще штука безусловно полезная, но очень нишевая. Для формального описания алгоритмов аля «технологический процесс приготовления борща» подходит идеально :)
Хотя всё равно не до конца ясно как будет выглядеть эквивалентная схема борща на ДРАКОНе. Развалится на 6-7 схем, в каждой из которых одна функция с параметрами? Как будет выглядеть силуэт? Тык rykkinn
Плохо будет выглядеть.
Схема борща — параллельная, допускающая одновременную обработку несколькими процессорами-поварятами.
А схемы на Драконе — это просто state-machine для одного процессора, строго.
Схема борща — параллельная, допускающая одновременную обработку несколькими процессорами-поварятами.
А схемы на Драконе — это просто state-machine для одного процессора, строго.
А как бы Вы разбили программу приготовки борща на параллельные процессы?
дел
Если схематически, то разбивка уже написана на технологической схеме, причем без привязки к кол-ву процессов и способу их синхронизации. На Драконе так общо нарисовать не получится.
Все задачи «первичная обработка» могут выполняться параллельно, следовательно, запускаем их одновременно.
К некоторым из них добавляем в конвейер задачу «нарезка».ле
Перед тушением ставим барьер.
Аналогично после закладывания.
В конце задача «Доведение до вкуса» уже для одного процесса.
P.S. Показал жене — она сказала, что это неправильный борщ, в нем нет ключевого компонента — мяса.
Все задачи «первичная обработка» могут выполняться параллельно, следовательно, запускаем их одновременно.
К некоторым из них добавляем в конвейер задачу «нарезка».ле
Перед тушением ставим барьер.
Аналогично после закладывания.
В конце задача «Доведение до вкуса» уже для одного процесса.
P.S. Показал жене — она сказала, что это неправильный борщ, в нем нет ключевого компонента — мяса.
Получится. Надо только понять, что тут два процесса, связанные через буфер. В организации производства он называется задел. Типичная задача согласования операций с разной производительностью.
Разве я сказал, что процессов два? Или это следует из технологической схемы? В том то и дело, что технологическая схема не определяет параллельность, но дает возможность её сделать.
В Драконе же придется каждый процесс описывать отдельно, потому что его синтаксис не предусматривает распараллеливание процессов. И вообще, Дракон позиционируется как язык программирования, поэтому имеет ограничения.
Если знать, что такое межоперационный задел, то два примитива. Ничего хитрого.
Круто, когда строим ракету. В «бизнесе» становится недостатком, т.к. не к месту добавленное условие… может заставить переделывать половину программы.
Работаю с ДРАКОНом для ТЗ «бизнесе». Проблемы такой не заметил. Заказчики постоянно добавляют что-нибудь не к месту. Дорисовываю диаграммы, и если добавления содержат противоречия, эти противоречия сразу видны.
А схема с борщом грамотная, кстати.
Судя по интерфейсу, представленному на рис. 20, DRAKON Editor стал экспортным продуктом?
Насколько он популярен в зарубежной среде?
Насколько он популярен в зарубежной среде?
Подозреваю что в зарубежной среде Flowcode гораздо популярней DRAKON Editor.
Вот тут статистика есть.
не знаю почему, но у меня не отображается ни одна картинка из статьи. в комментах картинки вижу все, а в статье ни одной.
Этот Ваш Дракон — это правильно, но к сожалению он не развился. Взгляните на Matlab/Simulink/Stateflow сегодня — это то, чем мог бы стать Дракон, если бы развивался дальше. Представление алгоритмов как в виде блок-схем, так и в виде автоматов состояний. Автоматическая генерация кода для процессоров и ПЛИС. Используется и в космосе и в автомобилестроении. Моделирование — важнейшая функция. Сотни различных тулбоксов от DSP и до силовой электроники.
Всего не пересчесть.
Matlab/Simulink/StateflowЦена? Не для студента, если что.
если бы развивался дальше.Видимо, теперь, когда есть опенсорц редактор, можно и развивать. Потому и статья появилась.
Цена? Не для студента, если что.
Матлаб для студентов бесплатен. Цена для промышленности высокая, да — но это компенсируется повышенной скоростью разработки и меньшими вложениями в программирование и отладку.
Для персонального использования матлаб можно купить за 139$, далее по 29$ за симулинк и каждый тулбокс (справедливости ради стоит отметить что некоторые тулбоксы для персонального использования не продаются, но большинство доступны).
Так этот редактор существует уже много лет. И развился вполне себе. Сначала там не было кодогенерации, а потом появилась, и новые языки добавляются!
Работаю лет 5 на Simulink + TargetLink, все круто, но код приходится часто напильником дорабатывать.
Но плюсов всё таки больше.
Но плюсов всё таки больше.
православненько
UFO just landed and posted this here
Есть ДРАКОН-Erlang, но не знаю, насколько удобно и полезно.
В ДРАКОНе есть параллельное исполнение.
Пример с борщом.
Другое дело, что DRAKON Editor это не поддерживает на данный момент.
Приходится обходиться другими методами, включая конечные автоматы в качестве акторов.
Пример с борщом.
Другое дело, что DRAKON Editor это не поддерживает на данный момент.
Приходится обходиться другими методами, включая конечные автоматы в качестве акторов.
UFO just landed and posted this here
Есть иконы "Ввод" и "Вывод". Применются для обозначения приёма и посылки сообщений.
Есть икона "Полка". Там в верхней части обычно пишут исполнителя (если их несколько). Но можно написать отправителя и получателя сигнала. Например: Браузер > Сервер приложения
См. набор икон в https://ru.wikipedia.org/wiki/ДРАКОН
Отлично! Давно искал аутлайнер для lua!
Алгоритм для "Фрегата" с разворотом на 355 градусов на ДРАКОНе писали?
Можно ли писать на многоязычном ДРАКОНе: часть, где требуется скорость, на С, остальное на питоне, например, с тем, чтобы биндинги сгенерировались автоматически? Ну или php+js+html
Мой вариант шампура
Не для создания, а понимания кода.
В каких конкретно проектах он используется на практике?
Структурное программирование делает то же самое для «текстовых» программ без изобретания велосипедов.
Он привнёс в блок-схемы структуру, порядок и единообразие. Предсказуемость и опрятность ДРАКОН-схем приводят к тому, что визуальное программирование работает.
Структурное программирование делает то же самое для «текстовых» программ без изобретания велосипедов.
UFO just landed and posted this here
В моём «шампуре» Yes — это всегда направо, т.к. любой положительное можно инвертировать: А < Б на А > Б, «дождь идёт?» на «дождь не идёт»…
Справа налево можно исключительно через диагональные линии.
__________________________________________________________________
Забыл, что правый шампур — отброшенный сложный вариант. В нём можно легко перемещаться и вправо и влево, главное знать, что входы выше горизонтальной середины блока, выходы равны или ниже середины блока.
Шампур
Справа налево можно исключительно через диагональные линии.
__________________________________________________________________
Забыл, что правый шампур — отброшенный сложный вариант. В нём можно легко перемещаться и вправо и влево, главное знать, что входы выше горизонтальной середины блока, выходы равны или ниже середины блока.
Ну может профи программистам оно и не нужно. А мне как не профи пишущему программки для себя очень нравится(скажу больше мой мозг испытывает своеобразное удовольствие от вида этих блок схемок)). Всегда написание более-менее сложной программки начинал с блок-схемы, начиная от самой общей, и постепенно расписывая, и уточняя, пока не понимал что смогу по нарисованному, без лишнего перегрева мозгов написать код. А тут естественное завершение такого подходя, блок схема переводит себя в код сама. Так что думаю у визуального программирования есть перспективы и своя ниша потребителей.
Я вам больше скажу — мне тоже нравится. Красиво и [относительно] удобно. Если хочется понять, но не модифицировать. Но я сейчас посмотрел на один из наших файлов — за неделю туда внесено тремя разработчиками порядка 20 правок. Из них большая часть «наложилась» без конфликтов, но три (или 4?) вызвали конфликт и их пришлось при слиянии «разводить» руками.
И как это будет всё происходить при визуальном редактировании? Понятно, что не все файлы так активно меняются, но заранее ж не угадаешь…
У меня есть ощущение, что при увеличении (и усложнении!) программ мы достаточно быстро в эту проблему будем упираться — то при разработке больших (и, соответственно, сложных) программ эта технология — скорее минус, чем плюс.
А небольшие (и, соответственно, несложные) программы, как бы, и без этого можно разрабатывать. Так кому оно нужно? Тому, кто разрабатывает несложные, но крайне ответственные программы? Ну теоретически — да, возможно, а на практике… есть ли выигрыш?
И как это будет всё происходить при визуальном редактировании? Понятно, что не все файлы так активно меняются, но заранее ж не угадаешь…
У меня есть ощущение, что при увеличении (и усложнении!) программ мы достаточно быстро в эту проблему будем упираться — то при разработке больших (и, соответственно, сложных) программ эта технология — скорее минус, чем плюс.
А небольшие (и, соответственно, несложные) программы, как бы, и без этого можно разрабатывать. Так кому оно нужно? Тому, кто разрабатывает несложные, но крайне ответственные программы? Ну теоретически — да, возможно, а на практике… есть ли выигрыш?
Здорово напоминает язык SFC из стандарта IEC61107.
UFO just landed and posted this here
Можно ли как-то на Драконе изображать схемы в нотации ЕРС? Или в близкой к ней, т.е. указывать входящие и исходящие документы (в конкретную функцию), события и роли (кто выполняет операцию — функцию).
Пусть так, но зачем изобретать было велосипед, если уже был ЕРС?
А у графического языка имеются фундаментальные преимущества по сравнению с текстом.
Пусть так, но зачем изобретать было велосипед, если уже был ЕРС?
Можно ли как-то на Драконе изображать схемы в нотации ЕРС?
bipiem, вы задали важный и интересный вопрос. Событийная цепочка процессов (EPC — event-driven process chain) — тип диаграммы, используемой для бизнес-моделирования и для улучшения бизнес-процессов.
Вы правы, язык ДРАКОН можно использовать для описания и моделирования бизнес-процессов. Однако это уже не будет EPC-нотация. Потому что у ДРАКОНа есть своя собственная нотация, гораздо более выразительная и предназначенная для точного описания алгоритмов. В данном случае, бизнес-алгоритмов, то есть потоков работ (workflows).
С уважением,
Владимир Паронджанов
Вы правы, язык ДРАКОН можно использовать для описания и моделирования бизнес-процессов. Однако это уже не будет EPC-нотация. Потому что у ДРАКОНа есть своя собственная нотация, гораздо более выразительная и предназначенная для точного описания алгоритмов.
Можно узнать, чем она более «выразительная» по сравнению с ЕРС?
Заодно, и чем лучше «для точного описания алгоритмов» чем BPMN?
А заодно: чем лучше «великой и могучей» нотации ArchiMate, предназначенной для описания (страшно даже произнести) Enterprise Architecture:
habrahabr.ru/post/345948/#comment_10607662
perfect_genius написал:
Вы правы, любое положительное высказывание теоретически можно инвертировать.
Но здесь есть трудность, если учесть необходимость соблюдения норм профессиональной терминологии в терминах предметной области.
Отрицание может внести затруднение в понимание сути вопроса (если учитывать требование когнитивной эргономики).
Уместно привести слова Эдварда Йодана:
Источник: Эдвард Э. Структурное проектирование и конструирование программ. — М.: Мир, 1979. — 415 с. — С. 252.
По этой причине в языке ДРАКОН предусмотрены оба случая:
1) Да вниз, Нет вправо
2) Нет вниз, Да вправо.
Такой подход создает наибольшую удобочитаемость и облегчает чтение сложных программных текстов.
С уважением,
Владимир Паронджанов
В моём «шампуре» Yes — это всегда направо, т.к. любой положительное можно инвертировать: А < Б на А > Б, «дождь идёт?» на «дождь не идёт»…
Вы правы, любое положительное высказывание теоретически можно инвертировать.
Но здесь есть трудность, если учесть необходимость соблюдения норм профессиональной терминологии в терминах предметной области.
Отрицание может внести затруднение в понимание сути вопроса (если учитывать требование когнитивной эргономики).
Уместно привести слова Эдварда Йодана:
Если это возможно, то избегайте отрицаний в булевских выражениях; представляется, что их понимание составляет трудность для многих программистов.
Источник: Эдвард Э. Структурное проектирование и конструирование программ. — М.: Мир, 1979. — 415 с. — С. 252.
По этой причине в языке ДРАКОН предусмотрены оба случая:
1) Да вниз, Нет вправо
2) Нет вниз, Да вправо.
Такой подход создает наибольшую удобочитаемость и облегчает чтение сложных программных текстов.
С уважением,
Владимир Паронджанов
Почему в ДРАКОНе не используется цвет? Ведь цвет значительно облегчает ориентироваться в мире.
Положительные переходы можно было бы синей линией, отрицательные красной.
Просто раз уж избавляемся от текста, то надо бы до конца.
Положительные переходы можно было бы синей линией, отрицательные красной.
Просто раз уж избавляемся от текста, то надо бы до конца.
perfect_genius
Вы правы, цвет очень помогает. В ДРАКОНе цвет используется, например, для заливки фона. Это помогает отделить фигуру от фона и направить внимание читателя на фигуру, то есть на дракон-схему.
В остальных случаях с цветом нужно быть осторожным. Неумелое использование цвета может вызвать раздражение у читателя. Тут необходимо пробовать и советоваться с художниками, специалистами по цвету.
С уважением,
Владимир Паронджанов
Почему в ДРАКОНе не используется цвет? Ведь цвет значительно облегчает ориентироваться в мире.
Вы правы, цвет очень помогает. В ДРАКОНе цвет используется, например, для заливки фона. Это помогает отделить фигуру от фона и направить внимание читателя на фигуру, то есть на дракон-схему.
В остальных случаях с цветом нужно быть осторожным. Неумелое использование цвета может вызвать раздражение у читателя. Тут необходимо пробовать и советоваться с художниками, специалистами по цвету.
С уважением,
Владимир Паронджанов
Не хватает третьего измерения. И четвёртого.
Sign up to leave a comment.
Визуальное программирование на языке ДРАКОН