Вышел DRAKON Editor 1.5 с генерацией кода

Если я модифицирую сгенерированный код, изменения буду отражен в Дракон-диаграмме?

Если я пару байтов в бинарнике изменю, изменения будут отражены в исходниках?

Чем он лучше давно известных и отработанных систем документирования, вроде IDEF?

Если я пару байтов в бинарнике изменю, изменения будут отражены в исходниках?

На сколько я понимаю, многие программы для работы с UML могут генерировать и код по диаграммам и диаграммы по коду

Если я модифицирую сгенерированный код, изменения буду отражен в Дракон-диаграмме?

Если я пару байтов в бинарнике изменю, изменения будут отражены в исходниках?

Я так понимаю, это ответ «нет», основанный на опыте работы с Драконом?

Это не гибко так рисовать...

текст он же линеен, а фигурки - вполне себе 2D

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

Зарепорченный мною баг пофиксили за два часа — разработчикам респект :-)

ну если так втупую рассматривать, то текст тоже двумерный. строки, столбцы, буквы тоже фигурки двумерные.

а код на питоне вообще не преобразуется в однострочник.

Я - да, а еще я знаю, что визуальные языки вышли из моды по вполне практическим причинам.

Осталось выяснить, почему этим хитрецам из NI до сих пор удаётся за немалые бабки продавать своё LabView (кстати, и под линукс тоже)...

тут проще конечными автоматами или всякими UML воспользоваться

А Дракон - это не подобие UML? (Я просто не в курсе.)

сам по себе текст - одномерен (одно направление, последовательнось букв - линейна)

я видел развлекуху на плюсовых шаблонах где делали объекты которые надо было рисовать текстом.

буквально чтобы объявить прямоугольник MxN нужно было его из вертикальных и горизонтальных черточек нарисовать. и вот эта двумерность дракона точтно такая же. визуально он представлен двумерно, текст тоже.

а если в мерность содержимого лезть, так там графы с деревьями полезут. какие там размерности?

там графы с деревьями полезут. какие там размерности?

Деревья планарны. Многие графы - тоже.

Я - да, а еще я знаю, что визуальные языки вышли из моды по вполне практическим причинам.

Осталось выяснить, почему этим хитрецам из NI до сих пор удаётся за немалые бабки продавать своё LabView

Заметь - единственный пример визуального языка, приведенный в этом треде - LabView.

ну так и текст в те же самые графы и отображается.

Так я не спорю, что единственный. Тем не менее это лидер в своей отрасли (сбор данных). И умирать пока совершенно не собирается...

ну так и текст в те же самые графы и отображается.

Вот эти графы и рисуют наглядно, вместо того, чтобы вчитываться в тексты. Посмотри ГОСТ-овские блок-схемы, посмотри диаграммы UML. Это общепринятые практики, и таковыми они стали не на пустом месте.

А дракон всего лишь делает блок-схемы эргономичными, то есть повышает удобство их восприятия человеком.

Похоже, вот квинтэссенция того, для чего дракон с успехом применялся на практике:

Дракон полностью изменил взаимодействие
Разработчиков-комплексников и программистов

Раньше работа была организована так. Комплексник выдавал в отдел программирования бумажный документ — исходные данные на разработку программ и согласовывал его с программистом. Затем программист на основании этого документа разрабатывал программу.

На комплексном стенде обычно выяснялось, что программа работает неправильно. Кто же допустил ошибку: комплексник или программист? Чтобы выяснить это, обращаются к документу — исходным данным на разработку программы. Тут-то и возникает немая сцена. Выясняется, что в документе про это ничего не сказано. Или написано настолько коряво и двусмысленно, что понять можно и так и эдак.

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

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

В этом случае бумажный документ (исходные данные на разработку программы) уже не используется. Комплексник передает в отдел программирования не «грязную и путаную бумажку», а дискету с алгоритмом, который он (комплексник) разработал сам, своими руками — без помощи программистов.

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

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

Таким образом, при использовании ДРАКОНА реализуется мудрый принцип: кто обладает знаниями, тот и должен их формализовать. Знаниями о физике и порядке работы ракетного комплекса обладает специалист-комплексник, а никак не программист. Поэтому комплексник и должен свои знания формализовать. В этом случае бесконечная игра в «испорченный телефон» между комплексником и программистом полностью исключается.

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

В итоге глубина интеллектуальной проработки алгоритма существенно возросла. Качество работы улучшилось на порядок. Производительность труда увеличилась.

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

Похоже, вот квинтэссенция того, для чего дракон с успехом применялся на практике:

Сказочка это. В реальности, предметник сам не знает точно, что ему нужно.

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

То есть функция отдела программирования - произвести автоматическую трансляцию кода? Я плакал.

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

Может быть, он стал ее понимать лучше.

я с наглядностью и не спорил. наглядность, вроде, хорошо.

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

Сказочка это. В реальности, предметник сам не знает точно, что ему нужно.

Вот у меня с представителями маркетинга в нашей конторе именно такие отношения. Они придумывают вундервафлю, и хотят, чтобы мы ее запрограммировали. Желаемое, требуемое поведение вундервафли можно обсуждать с ними по многу часов вподряд, совещание за совещанием. Они путаются в своих мыслях и идеях, поскольку оперируют большим набором важных, но разрозненных юзкейсов; они не в состоянии держать в своей голове все кейсы одновременно; сегодня им кажется разумным одно, а завтра - прямо противоположное. Они в письменном виде фиксируют итог каждого совещания, но это нихрена не помогает: итоги очередного совещания противоречат итогам предыдущих, описания урывочны, а местами - откровенно бредовы. Просто цирк какой-то, но это происходит на практике, причем все участники стараются изо всех сил сделать как можно лучше. Поставить точку помогает высокоуровневая блок-схема. Рисуешь, отображая на ней все существенные по твоему мнению аспекты, и показываешь им с вопросом: «так правильно?» Они вспоминают очередные несколько кейсов, и говорят: «не, не правильно, потому что бывает еще вот такой расклад, и в нем важно чтобы бла-бла-бла». Ты им в ответ: «нарисуйте тогда правильную схему». Рисуют, опираясь на твою, как на пример. И тут наступает счастье: они наконец-то перебрали все свои сценарии на схеме (ведь для этого не нужно держать в голове _все_ сценарии _одновременно_, достаточно перебирать их один за другим), успокоились, и расписались под ней. А мы можем спокойно браться за реализацию.

Может быть, он стал ее понимать лучше.

Это заметно снижает вероятность того, что он по итогам демонстрации уже написанной программы заявит «всё неправильно, всё переделать!!!1»

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

GIGO

Рисуют, опираясь на твою, как на пример. И тут наступает счастье: они наконец-то перебрали все свои сценарии на схеме

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

такие моменты обстоятельно разобраны в упомянутой книге «Как улучшить работу ума». Схемы Дракона должны быть понятны и непрограммистам. И вообще, он позиционируется не сколько для программирования, сколько для универсальной формализованной межотраслевой коммуникации.

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

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

Приходить с фразой «забыли фишку» они любят за неделю до официального релиза, но это уже отдельная проблема :)

я видел развлекуху на плюсовых шаблонах где делали объекты которые надо было рисовать текстом.

а я видел как в Blender -е из 2D фигур делали 3D объекты, но они от этого не становились настоящим 3D, это всеголишь представление 3-ех мерных фигур в 2D пространстве..

а если в мерность содержимого лезть, так там графы с деревьями полезут. какие там размерности?

не размерности - а пространство, у текста оно одномерно (это не я придумал), символ за символом - в одном направлении..

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

Я думаю, что здесь как в старом анекдоте: «Объясняю им раз, другой, третий, уже и сам понял, а они - всё никак». Ты заставляешь их объяснять свои идеи тебе, и в результате они их сами начинают понимать. Диаграммы или нет - дело десятое.

У нас АБСОЛЮТНО то же самое на производстве! Manhunt правильно сформулировал: люди не могут удержать в голове все сценарии одновременно, а тем более объяснить их в устной и даже письменной речи.

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

мда, в нынешнем виде DRAKON Editor не пригоден для рисования сложных запутанных схем, а для простых - зачем Дракон?

Что помешало использовать для рисования блок схем http://adaptagrams.sourceforge.net/ / http://www.graphviz.org/ ?

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

символ за символом - в одном направлении.

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

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

не пригоден для рисования сложных запутанных схем

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

одномерное пространство легко отображается на двумерное той же мощности.

Такое отображение не изоморфно, а значит грош ему цена.

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

а, то есть то, что для замены «print(„hi!“)» на «print(„hello, world!“)» приходится перерисовывать совершенно соседнюю ветку кода - это поощрение правильного стиля программирования...

для замены «print(„hi!“)» на «print(„hello, world!“)» приходится перерисовывать

Любопытно. Можете продемонстрировать, где в этом сценарии должны быть уместны «сложные запутанные схемы»?

Такое отображение не изоморфно, а значит грош ему цена.

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

так что текст именно программы как одномерную фигню воспринимать тоже не очень-то полезно.

Можете продемонстрировать, где в этом сценарии должны быть уместны «сложные запутанные схемы»?

очевидно, ничего сложного и запутанного в этом сценарии быть не должно, но из-за неудачного(IMXO, естественно) лук&фил даже та-же замена текста(а уж тем более добавление скажем, «Case» в «Select») уже иногда влечёт необходимость перерисовывать соседние участки схемы, причём количество лишних телодвижений на одно нужное прямо пропорционально размеру схемы, при этом двигая какой-нибудь блок можно запросто порвать нужные и создать ненужные связи где-нибудь за границей экрана.
В результате больших схем в DRAKON Editorе нет, в каждом проекте присутствует множество маленьких дракон-схем, взаимосвязи между которыми никак не отображаются, обеспечиваются исключительно средствами стороннего языка и помнятся вручную.

IMXO, если использовать готовую библиотеку для рисования схем с автоматическим размещением элементов и сделать возможность развернуть каждый квадратик «Action» в участок дракон-схемы и свернуть любой имеющий один вход и выход участок дракон-схемы в квадратик «Action» - ДРАКОН стал-бы куда дружелюбнее.

Интересная мысль, кстати... А такого ещё нет?

Можно подробнее про нити в Драконе? Я что-то ничего такого не помню.