gifts2017

1С + Дракон?

Опубликовал Владимир Потапов (keleg) в раздел Программирование - Теория программирования

Некоторые мысли про применение космических технологий к нашей 1С :-)

http://www.computerra.ru/readitorial/418507/

Очень интересная статья про визуальное программирование процедурных языков (статья вводная, конечно, идти по ссылкам внизу, все книги есть в онлайне)

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

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

Почему?

"Рисование" программы на понятном заказчику языке, акцент на понятности работы программы для конечного пользователя!

Защищенность от написания ошибочного кода (!) путем повышения эргономики разработки.

Простая адаптация к процедурным языкам без заголовков и предописаний (а язык 1С именно такой!)

 

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

 

Ребят, кажется, это шанс сделать из 1С не просто хорошую рабочую систему, а систему, которая будет революционной в RAD, как когда-то Delphi.

Ссылка на книгу разработчика (Автор про нее знает и одобряет такое распространение его идей, так что даю с чистой совестью)

Дракон-редактор (Интерфейс так себе, но уже работает)

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Александр Рытов (Арчибальд) 14.04.09 11:13
Ну надо же. В 84-86 годах на всяких ведомственных семинарах и конференциях мне доводилось делать доклады по графическому программированию. Не ожидал, что графическое программирование кто-то доведет до ума - и это при том, что в 85, кажется, году ВАК перестала принимать к рассмотрению "лингвистические" диссертации.
+ за ностальгию.
2. Василий Демидов (Душелов) 14.04.09 11:16
3. Александр Рытов (Арчибальд) 14.04.09 11:24
(2) Там наработочки по эргономике приличные. Полезны для упорядочения мыслей заказчика/разработчика. Но вот транслятора/интерпретатора, похоже, нет, либо есть, но для очень экзотической платформы (у военных много эксклюзивных машин было тогда).
4. Владимир Потапов (keleg) 14.04.09 11:30
Да, там интерпретера нет, (кроме военного) есть только транслятор в Oberon :-)
Но вообще-то наваять интерпретер сейчас не такая сложная штука для знающих yacc.
Но вот чем больше читаю, тем больше мне кажется что к 1С эта штука применима. Действительно - сейчас в управляемом приложении (8.2) есть компоновка для отчетов и автоформы. Осталось визуализировать всяческие циклы и if ы, что и делается здесь :-)
И получим... ой, самому страшно мечтать становится.
Но мечтать не вредно, вредно не мечтать!
5. Василий Демидов (Душелов) 14.04.09 11:36
Циклы-циклами, а запросы как будут визуализированы?
6. Василий Демидов (Душелов) 14.04.09 11:36
7. Владимир Потапов (keleg) 14.04.09 11:53
Дык, они уже неплохо визуализированы :-) Нафига изобретать велосипед еще раз? Сделать одну из иконок запросом и все... он же линеен по алгоритму.
8. Александр Рытов (Арчибальд) 14.04.09 13:06
Владимир, а тебе редактор драконов скачать удалось?
9. Александр Окулов (PowerBoy) 14.04.09 13:50
Автор интегрированной среды DRAKON – 1С программист 2-й категории Геннадий Николаевич Тышов :)
Очень интересно - почитаю. Спасибо.
10. Сергей Дудаков (Anything) 14.04.09 15:32
Спасибо за ссылку. Мозг поразмять есть чем. :)

(5) Визуализировать запросы можно. Я даже придумывал нотацию для описания запросов в 1С. Искал готовую, но не нашел, пришлось придумывать. Помогла один раз при разгребании головоломного запроса. :)
11. Александр Рытов (Арчибальд) 14.04.09 16:55
Поигрался с редактором. Все ж таки минимально серьезный алгоритм сразу теряется в квадратиках. Наверное, такая штука хороша при преподавании информатики - в плане развития систематического мышления и архитектурных приемов. В исходной предметной области, когда общаются инженеры с алгоритмистами - тоже, наверное, хорошо. Управленческий сценарий написать можно. А учет - вряд ли.
Но и перечисленное весьма обширно.
12. Владимир Потапов (keleg) 16.04.09 03:52
(11) Не-а, не теряется. Если правильно все делать - разбивать на ветки и использовать свертку процедур, то любой алгоритм остается обозримым.
Но, конечно, экран желательно побольше чем 15 дюймов :-)
Я тут посмотрел как делаются компилеры на .net - семь экранов кода.
Думаю, попробовать сделать свой дракон-редактор простенький, который бы exe-шник компилил.
13. Владимир Потапов (keleg) 16.04.09 03:55
Там очень прикольно обходятся некоторые 1С-проблемы. Например - длинные переменные, дающие необозримый код. Присваивание - в две строчки, сверху переменная, снизу выражение.
Использование для длинных переменных алиасов-псевдонимов, чтоб формулы писать.
14. Владимир Потапов (keleg) 16.04.09 04:39
Добавил прямые ссылки на основную книгу и на дракон-редактор
15. Александр Окулов (PowerBoy) 21.04.09 06:52
(12) Был бы хороший ActiveX по рисованию схем, тогда можно было бы прикрутить его в обработке и формировать алгоритмические схемы уже в контексте конфигурации, а отдельный редактор не взлетит :)
16. Sensey Master (MSensey) 21.04.09 09:53
Не боитесь, что вместо нас начнут бухгалтера дорабатывать конфигрураци? :)
17. Владимир Потапов (keleg) 21.04.09 09:55
(15) ActiveX есть, но они только рисунок выдают, а хочется сразу код :-)
(16) И пусть. Я лучше учет буду ставить в организациях, это всяко интереснее, чем тупое кодирование глючных алгоритмов. Программированию - высокий уровень! :-)
18. Sensey Master (MSensey) 21.04.09 09:56
Хотя, что боятся, ведь из 1с-ков хорошие бухгалтера получаются ))
19. Александр Рытов (Арчибальд) 21.04.09 10:02
(16) Им давали КОБОЛ в свое время. И незаметно было, чтоб кто-то все бросил и программить начал.
20. Владимир Потапов (keleg) 21.04.09 10:04
(16) Ну, значит КОБОЛ несовершенен. Excelом же они пользуются и вовсю!
21. Александр Рытов (Арчибальд) 21.04.09 10:05
(18) Предлагали мне и главбухом, и финдиректором у себя. Влом, однако.
22. Владимир Потапов (keleg) 21.04.09 10:07
(21) Не. Программировать это ведь не писать код, это ставить процессы, чтоб они потом независимо от тебя работали. Выработка технологий. А кто их исполняет - процессор или люди, это уже вопрос второй.
Все равно уже сейчас написание инструкций и обучение бывает не менее важно, чем само кодирование.
23. Александр Рытов (Арчибальд) 21.04.09 10:20
(22)Согласен. Кодирование, скорее, отвлекает от программирования, чем составляет основу.
"Хорошим программистом становится только тот, кто своевременно уходит от пульта" (с) Э.Дейкстра.
24. Владимир Потапов (keleg) 21.04.09 10:23
(23) Тут в обсуждении на партнерском форуме мысль возникла.
- Хороший программист думает сразу на языке программирования!
- Т.к. скорость думания зависит от совершенства языка (см. хотя бы алгебру до изобретения формул - ужас полный), значит можно реально повысить скорость программирования. В общем-то об этом книга и написана.
25. Александр Рытов (Арчибальд) 21.04.09 10:37
(24) Вах, зачем нехорошим программистом меня обозвал? ;-)
Я на русском языке думаю. Ежели "Все видит, все понимает, а сказать не может" - это умный собак, а не прогрпммист.
26. Артур Аюханов (artbear) 21.04.09 12:17
(24) Мысль про "думает сразу на языке программирования" неверна, это давно известно :(
Хороший разработчик как раз не должен думать на языке программирования, он должен разрабатывать свои программы с использованием языка программирования.
Например, в 1С нет ООП, но можно придумать обходные пути.

ЗЫ рекомендую почитать книгу Макконелл "Совершенный код" - куча всего полезного.
На 1С мир еще не заканчивается, и есть куча способов обойти несовершенство конкретного языка программирования.
27. Владимир Потапов (keleg) 21.04.09 12:24
Ну, про "думает на языке" говорил мой оппонент.
(задумался, на каком же языке думаю я? :-)
Прикол еще и в том, что в общем-то если убрать управляющие конструкции то большинство языков очень похожи.
28. Александр Окулов (PowerBoy) 21.04.09 12:41
(17) А что у Вас за ActiveX? Можно на него глянуть?
29. Владимир Потапов (keleg) 21.04.09 12:49
(28) Я подробно не смотрел, т.к. исходная задача была найти что-то в исходниках, чтоб текст программы или даже код генерить.
Где-то в районе
http://sharptoolbox.com/categories/graphics
или
http://www.devdirect.com/ALL/DIAGRAM_PCAT_1900.aspx
видел бесплатную ActiveX для vision-like диаграмм.
PowerBoy; +1 Ответить
30. Владимир Паронджанов (Паронджанов) 21.04.09 21:52
Уважаемые коллеги!

Меня зовут Владимир Паронджанов. Я автор книги "Как улучшить работу ума: Алгоритмы без программистов -- это очень просто! М.: Дело, 2001. 360с".
Я также автор статьи в Компьютерре, о которой Вы знаете. Меня очень интересует тема Вашего обсуждения. Если ко мне есть вопросы, я с удовольствием отвечу.

Примерно в 2000 году специалист по 1С Александр Шилин из города Волжский написал материал под названием "Дракон помогает бухгалтеру" и прислал его мне. В нем сравниваются тексты 1С и дракон-схемы для алгоритмов "Работа с документом Приходный кассовый ордер" и "Обработка счета 62". Я решил использовать этот материал при переиздании своей книги и вставил его в одну из глав. Книга еще не опубликована.
Специально для Вас я повесил все это на Народе. Если хотите, можете скачать.

http://narod.ru/disk/7934439000/%D0%93%D0%BB%D0%B0%D0%B2%D0%B0%2016%20%D1­%82%D0%BE%D1%80%D0%B3%D0%BE%D0%B2%D0%BB%D1%8F%D0%9D%D0%B0%D1­%80%D0%BE%D0%B4.doc.html

Мой мейл vdp2007@bk.ru
Московский тел (495)331-50-72

Желаю успеха Вашему обсуждению.
ILM; PowerBoy; +2 Ответить
31. Владимир Паронджанов (Паронджанов) 21.04.09 22:30
По поводу дискуссии Арчибальда и keleg в пунктах 11 и 12.
Предлагаю вашему вниманию

РЕКОМЕНДАЦИИ ПО ИСПОЛЬЗОВАНИЮ СИЛУЭТА
И ПРИМИТИВА

1. Силуэт — главное достоинство языка Дракон. Более того, силуэт — его ЕДИНСТВЕННОЕ достоинство.

2. Примитив не в счет, так как его вообще не следует использовать (почти).

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

4. Тем не менее, полностью отказываться от понятия «примитив» не следует по двум причинам.

5. Первая причина — педагогическая. Примитив — это прообраз (зародыш) ветки. Основные понятия и правила Дракона удобно объяснять на самой простой модели. То есть на примитиве. И только после этого переходить к рассказу о силуэте.

6. Вторая причина — необходимость описания «мелких огрызков». Откуда берутся «мелкие огрызки»? В процессе декомпозиции силуэта может случиться (очень редко), что какая-нибудь вставка окажется очень простой, элементарной. Настолько простой, что ее неудобно представлять в виде силуэта. Такую вставку можно назвать «мелким огрызком». Вот в этом (исключительном) случае полезно использовать примитив.

7. Добавим еще одну мысль. Ни в коем случае нельзя представлять программу как систему примитивов. Потому что в этом случае НЕВОЗМОЖНО БЫСТРО УВИДЕТЬ ГЛАЗАМИ, как эти примитивы логически связаны между собой. Чтобы понять эту связь, нужен трудоемкий мыслительный анализ, который требует усилий, отнимает время и снижает производительность труда.

8. Систему примитивов всегда можно превратить в силуэт. При этом каждый примитив превращается в ветку силуэта. (Иногда часть примитивов превращается в ветки силуэта более низкого уровня на лестнице декомпозиции).

9. В заключение повторим еще раз основные рекомендации.
• Алгоритмы и программы следует изображать как силуэты.
• Сложные алгоритмы и программы следует изображать как силуэты, в которых многократно используются иконы «вставка». Последние, в свою очередь, раскрываются как силуэты и т.д.
• Примитивы рекомендуется не использовать совсем или использовать только в крайних случаях.
32. Олег Пономаренко (O-Planet) 21.04.09 23:12
Посмотрел материал. Интересно. Так и не понял, правда, чем указанное графическое представление отличается от блок-схем. Или блок-схему отсюда берут начало? Но не в этом дело. В сложных программах такое представление требует интеллектуальной, многоуровневой графической среды. Кстати, встречал такую среду, когда немного работал с ЧПУ. Был дорогущий пакет от Siemens, который позволял программировать полный цикл работы со станком именно по указанному принципу. Сперва программировался набор термов и лексем, применительно для описания предметной области и процессов станка. Затем составлялась блоксхема программы. После этого, можно было войти в любой участок блоксхемы и составлять программу, оперируя инженерными понятиями. Это мог делать уже не программист. В принципе, корректировать блоксхему тоже. Не скажу, что пакет был прост в эксплуатации. Описание занимало целый cd.
33. Сhe Burashka (CheBurator) 22.04.09 00:22
> Чтобы облегчить работу читателя и сделать алгоритм дружелюбным, разработчик дракон-схемы должен заблаговременно разрезать «длинную кишку» и разбить ее на смысловые части.
//
весь вопрос в том, что создание алгоритма и есть, по сути выделение смыслов, разбиение на процедуры/функции (реализующие эти смыслы)... готовый алгоритм красиво нарисовать - не сильно большая проблема (возмоно что при красивом рисовании смыслы будут упрощены/перетаосваны...)... ничего принципиально итересного не увидел.. тот же подход к проектированию "сверху вниз", который еще на вышке в 80-х годах усваивали... то, что разработана графическая удобная нотация - это да... а что еще???
34. Сhe Burashka (CheBurator) 22.04.09 00:29
> При этом разделение проблемы на N смысловых частей реализуется путем разбиения алгоритма на N веток.
...тихий хитрый ход, однако ;-)
разделение проблемы на ЭН смысловых частей как выполняется - паралельно, сорри, человек еще мыслить не научился (шизофреники разве), все мышление идет линейно, проблема "пробегается" (прикидывается варинт решения) по линейной неделимой ветке, и потом ее начинаем укрупнять и делить/паралелить на отдельные смысловые цепочки...
..имхо НЕЛЬЗЯ РАЗБИТЬ АЛГОРИТМ НА ЭН ВЕТОК. это разбиение на ЭН веток применяется к уже ГОТОВОМУ АЛГОРИТМУ (а не рождаются ветки в процессе разработки алгоритма) - только сначала этот алгоритм нариован ЛИНЕЙНО, "В КРУПНУЮ КЛЕТКУ", а дальше - разворачивай алгоритм до нужной степени детализации сверху-вниз - вычленяй отдельные смыслы - закидывай их в отдельные блоки/векти и т.д.
...
не втыкаю...
35. Сhe Burashka (CheBurator) 22.04.09 00:39
простое соображение: так сложилось, что для нас привычнее читать/воспринимать слева-направо и сверху-вниз. Дракон предлагает перевернуть сног на голову: читать сверху-вниз и слева-направо. Возьмем средней величины алгоритм, развернем его в Дракон-нотацию (причем не сильно подробно!) - количество веток будет - МНОГО! притом, что в самой ветке - примитивов не так уж и много... получается гораздо выгоднее располагать ветки горизонтально! а не вертикально - возьмите тот же учетный алгоритм 1ски - да это сполшные если-то-иначе (ветки) и повестьте их как гирлянды в дракон-нотации - будут висет как серпантин и мешаться друг-другу......
хотя, конечно, может я и не в теме...
36. Сhe Burashka (CheBurator) 22.04.09 00:49
> Чтобы алгоритм был понятным, он должен быть стройным, красивым, упорядоченным, то есть эргономичным.
- опочки.. много чего намешано, без обоснования...
рассмотрим классическую задачу - "перключателя", требуется значение "флажка" перключать между крайними значениями (0,1/1,2) - типичная 1совская задача с пометками; для набора флажков 1 и 2, самое красивое решение: ф=3-ф; - оно стройное! красивое! и еще визуально упорядоченное! (не в пример конструкциям если). А вот понятен ли с ходу данный кусочек алгоритма...???
37. Сhe Burashka (CheBurator) 22.04.09 00:54
> До сих пор мы пользовались правилом «Чем правее, тем хуже». Однако здесь оно не имеет смысла. Поэтому на рис. 20 выбрано другое правило «Чем правее, тем больше скорость ракеты».
- предлагается на этапе разработки алгоритма выбрать правило некой оценки "сложности/красоты" алгоритма... а неизвестно, что взять за такой критерний!!! вот неизвестно с ходу - и все! сложность/красота алгоритма определяется желаемой конечной целью и способом ее достижения... зачастую алгоритм строится для получения конечного решения, а не для получения красивого решения (известная трилемма "дешево, качественно, быстро")
38. Сhe Burashka (CheBurator) 22.04.09 00:56
> Правило хорошей хозяйки. Если постараться, порядок всегда можно навести.
Именно! даже штатные блок-схемы при правильной их отрисовке и выбора нужной стпени детализации будут понятны и прозрачны ничуть не менее чем Дракон-нотация...
39. Сhe Burashka (CheBurator) 22.04.09 01:01
из всего этого пока что какой можно сделать вывод? да как обычно: перед тем как что-то начать делать - спланируй и нарисуй, причем желательно - понятно не только для себя, но и для "соседа". Что предлагает Дракон - вполне определенную нотацию (набор правил), позволяющую "рисовать" понятные алгоритмы (на начальном этапе)... - чем это отличается от того, что мы знали раньше - да ничем...
40. Сhe Burashka (CheBurator) 22.04.09 01:08
> считаются вредными и категорически запрещены.
..масло масленное, типа как "немножко беременна". Т.е. что предлагает Дракон - он вдалбливает в меня мысль "ДАЖЕ НЕ ДУМАЙ О ТОМ, ЧТОБЫ НАРУШИТЬ ПРАВИЛО" (в противовес тому, что в иных "местах", допустимо такое: "если данное решение эффективно, то для его реализации можно пренебречь правилами) - вот и все... за счет уменьшения количества допустимых действий повышается "эффективность" алгоритма, заключающаяся в его визуальной понятливости для его быстрой оценки. - Это есть премущество? в каких-то местах (и их наверное подавляющее большинстов) - да (это как наборы очень коротких инструкций процессора - для реализации сложного оператора не изобретают сложный и дорогой автомобиль, а сажают на велосипед кучу маленьких гномиков)
41. Сhe Burashka (CheBurator) 22.04.09 01:16
> Таким образом, пример на рис. 24 подтверждает справедливость теоремы 21.
..очень опасное заявление.
рассмотрим теорему (типа ;-): для любых целых последовательных идущих друг за другом пятерки чисел справедливо равенство
a*a+b*b+c*c = d*d + e*e
..
например:
10*10+11*11+12*12 = 13*13+14*14
подтверждает ли данный пример справедливость теоремы - фигушки! (а по автору - подтверждает ;-) мало того - на числовой оси такая пятерка чисел - ЕДИНСТВЕННАЯ! сумма, кстати, = 365 (дней в году - ни на какие мысли не наводит?)
42. Сhe Burashka (CheBurator) 22.04.09 01:34
Например: у меня есть процедура, выполняющая некие действия.
и у меня есть потребность выполнить нескольо иные действия, очень похожие на исходные. Из типологии Дракона мне следует "нарисовать" две разные ветки, ибо смысл _немного_ разный? или все-таки усложнить исходную ветку, реализовав требуемый мне функционал за счет добавления в исходную ветку несколько "если"....? где он, баланс...?
43. Сhe Burashka (CheBurator) 22.04.09 01:38
ну и сама оболочка Дракон (по ссылкам) слабовата все-таки.. при выходе задается вопрос "сохранить - да или нет" и отсутсвует такая часто требуемая опция как отказаться от выхода!!! и продолжить работу!!!! видать Дракон проектировали не на Драконе... (а вот я когда писал диплом - транслятор отлаживал на самом себе - ккак снежный ком шло - быстро и эффективно)...
44. Сhe Burashka (CheBurator) 22.04.09 01:39
Хотя если применить предложенный Дракон-путь, то тут достаточно эффектно могут получиться конструкторы нужных инструментов/результатов"... некое ООП...
45. Владимир Потапов (keleg) 22.04.09 08:07
Спасибо, Че, за множество идей и комментариев.
Автор (Спасибо, Владимир! Я очень рад, что правильно понял Вас и мои выкладки совпали с вашими :-) очень правильно сказал, что силуэт это главное и единственное преимущество Дракона перед любой другой нотацией - текстовой или графической. А что главное в силуэте? Даже не ветки, они только иллюстрация принципа двумерности кода.
Любые сегодняшние блок-схемы это все равно одномерные структуры, параллельно-одномерность ведь тоже одномерность.
Создатель Дракона же "включил" в код двумерность изначально.
Возможно, это сделано не идеально. Но это ж не догма, это руководство к тому, чтобу думать и делать самому.
Дракон - первая цельная и полная система двумерного представления кода программы. И это, как минимум, ОЧЕНЬ интересно :-)
46. Александр Рытов (Арчибальд) 22.04.09 08:22
(32) Принципиально не отличается. Добавлен набор эргомомиеских правил для повышения наглядности = снижения вероятности ошибок.
(34) В корне не согласен, что всякая задача изначально линейна (последовательна). Диаграммы Ганта - яркий пример "крупноблочных" параллельных задач. Примерно так: мы хотим получить результат (набор данных) А. Он зависит от данных Б, В, Г , т.е. А=F(Б,В,Г). Ниоткуда не следует, что мы должны получать аргументы последовательно, если конечно нет зависимости, скажем, В=G(Б,Г). Как только готовы исходные данные для блока (функции), мы можем запускать процесс, вычисляющий эту функцию. Процесс завершает свою работу прерыванием, сигнализирующим о готовности данных.
Программируем (мыслим) мы, конечно, последовательно, т.к. имеем всего один процессор. Система прерываний, однако, существует - это всякому известно - так что налицо квазипараллелизм мышления.
47. Александр Рытов (Арчибальд) 22.04.09 08:32
+46 Конечно, способ решения задачи "цель -> способ" не очень характерен для учетных задач. Там "событие -> представление события" в основном используется. Исключение составляет, пожалуй, алгоритм закрытия периода - существенно ветвящийся.
48. Владимир Потапов (keleg) 22.04.09 09:31
(47) А как пример автора из приведенной главы? Конечно, он несколько устарел с точки зрения бухгалтерии (НП давно уже нет) но как принцип?
49. Александр Рытов (Арчибальд) 22.04.09 09:41
(48)Примеры красивые. И, наверное бухгалтеру понятны => полезны. Однако я бы рассматривал их скорее как иллюстрацию к комменту Че (45)
50. Владимир Паронджанов (Паронджанов) 22.04.09 15:46
(34) Che Burashka пишет:
"..имхо НЕЛЬЗЯ РАЗБИТЬ АЛГОРИТМ НА ЭН ВЕТОК. это разбиение на ЭН веток применяется к уже ГОТОВОМУ АЛГОРИТМУ (а не рождаются ветки в процессе разработки алгоритма)"

Ответ. Вы не совсем правы. Алгоритм (а если есть поддержка, то и программа) разрабатывется в процессе работы с дракон-редактором. Ветки рождаются в процессе разработки алгоритма. Допустим, Вы нарисовали алгоритма из 7 веток. Посмотрели - не понравилось (или увидели ошибку). Что делать?
Ответ ясен - исправлять, добавлять новые элементы, убирать старые, менять в них надписи и т.д. Одним словом, надо думать и работать.
В итоге число веток в вашем алгоритме может измениться. В конце работы их будет не 7, а 9 или 10 или еще что-нибудь. А может быть, их будет 6, потому что В сделали вставку (вызов процедуры, а в этой процедуре, в свою очередь, вы сделали (примерно таким же способом 8 веток.
51. Сhe Burashka (CheBurator) 22.04.09 15:57
(50) конечно же, согласен. Вопрос упирается в технологию работы и проектирования. Я очень сомневаюсь, что СРАЗУ при наброске дракон-алгоритма непростой задачи будет рождено 7-15 веток.. скорее всего, либо сначала будет глобальный примитив, или 2-3 укрупненные ветки...
Вообще, мне конечно понравилось, думаю взять на вооружение.
Было бы очень интересно посмотреть ролик разработки реального какого-нибудь (или учебного примера) поразвесистей размером - наблюдение за живой работой зачастую дает возможность оценить перспективность предлагаемого решения (Дракона как сути) гораздо быстрее и правильнее, чем чтение кучи книжек...
52. Владимир Паронджанов (Паронджанов) 22.04.09 16:05
По-моему, кто-то сказал, что дракон не поддерживает параллельные процессы.

Это не так. Дракон ПОДДЕРЖИВАЕТ параллельные процессы. См. "Как улучшить..." , стр. 171-173 (см. также ссылки на рисунки).

Желаю удачи вашей дискуссии.
53. Александр Рытов (Арчибальд) 22.04.09 17:55
(52)НЕ поддерживает - не говорилось. Поддерживает - да, но не ориентирован на них. Или точнее: ориентирован на вычисления, управляемые командами. А для создания истинно параллельных вычислительных систем/алгоритмов характерна архитектура, при которой вычисления управляются данными. Сидит супервизор и обслуживает очередь (толпу) процессов и очередь (толпу) процессоров.
54. Сhe Burashka (CheBurator) 24.04.09 01:29
Читаю книжку описания языка.
Глава 3. Циклы
Рис.69 Пример цикла "пока" - напанятна!!!
в примере: 3 вертикальные линии, 4 излома.
а если примитивы цикла насадить на левый шампур (поменяв да-нет местами) - будет 2 вертикали и 2 излома - почему не так???
55. Сhe Burashka (CheBurator) 24.04.09 01:32
56. Сhe Burashka (CheBurator) 09.05.09 06:31
Жалко, что ветка заглохла... Исходный форум по Дракону - взял "на карандаш"...
57. Владимир Потапов (keleg) 12.05.09 03:45
Я тут готовлю потихоньку большую статью про 1С в свете Oslo и Дракона.
Есть интересные мысли
58. Александр Окулов (PowerBoy) 12.05.09 06:26
(57) Где бы почитать про эту "Oslo"?
60. Александр Рытов (Арчибальд) 14.05.09 09:11
61. Сергей Дудаков (Anything) 04.07.09 11:23
(52) (56) (57) (60)

Лучше бы конечно ветка в форуме была... Комментарии сложно отслеживать.
Ну да ладно. Оживлю немного дискуссию. :)

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

По многим пунктам согласен с Сhe Burashka, и повторяться не вижу смысла.

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

|
-<>-
| |
| |
-----
|


Без этого правила схемы превращаются в мешанину с непредсказуемыми переходами (GOTO). Соответственно, ухудшается их читабельность и повышается вероятность ошибок.

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

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

Ну, и что еще поразило - это Дракон-редактор. И поразило не в лучшем значении этого слова. Редактор должен быть удобным и мощным, тогда дракон-схемы могли бы получить большее распространение, хотя бы на концептуальном уровне. К сожалению, автор программы похоже никогда не видел графических редакторов и не знаком с современным программным обеспечением, иначе, я не знаю, чем объяснить такой самобытный пользовательский интерфейс.
62. Сергей Дудаков (Anything) 04.07.09 11:25
Попробую еще раз изобразить рисунок... :)
Код
   |
 -<>-
|      |
|      |
 -----
   |
Показать полностью
63. Сергей Дудаков (Anything) 04.07.09 11:40
Кроме того, в Драконе не хватает формализованного представления данных.

Данные - это неотъемлемая часть алгоритмом, а иногда и алогритмообразующая, как заметил Арчибальд. Без описания данных дракон-схемы будут иметь чисто академическое применение. Этим же страдают и классические блок-схемы.

Вот, если придумать грамотную нотацию описания данных: простую, масштабируемую, аналитичную... и удачно вплетающуюся в схему алгоритма... То в паре с ней Дракон-нотация (или даже обычные блок-схемы) могли бы приобрести практическое значение.
64. Владимир Потапов (keleg) 06.07.09 07:15
(63) Я тоже, когда закапываюсь на тему 1С и Дракона сразу упираюсь в данные - для 1С они вполне алгоритмообразующи.
Минимально необходимой, возможно, может быть обычная реляционная схема данных (типа используемой в Access).
Но в любом случае трудно представить себе схему данных неортогональной схеме алгоритма, очень уж по-разному они устроены.
Хотя... возьмем схему проведения документа 1С. Реквизиты документа, взаимодействуя друг с другом (иногда довольно сложным образом) пишутся в регистр.
Схема тут просто просится! На входе реквизит(ы) документа, на выходе реквизит(ы) регистра, схема показывает их взаимодействие, можно проследить для каждого откуда он берется.
Почти как в стековой машине - есть начальное состояние (значение реквизита), есть операции над ним и результат - тоже состояние.
65. Владимир Потапов (keleg) 06.07.09 07:23
(61) Современные языки все же очень отошли от классической Виртовской схемы "один вход - один выход". return, break, continue - суть упорядоченные goto. А ведь есть еще и exception...
66. Александр Рытов (Арчибальд) 06.07.09 12:26
(63, 64) Думается, для сложной программной системы следует использовать два типа графов.
Дракон-схема уместна при реализации "черного ящика", полученного при проектировании системы "от данных", т.е. модуля, реализующего получение набора выходных данных из набора входных.
При самом проектировании выделяются этапы преобразований входного (для системы) набора данных в выходной с выделением промежуточных наборов данных. Здесь может появиться параллелизм, а в целом граф будет подобен графу (диаграмме) Ганта. Событие - это готовность набора выходных данных модуля, т.е. завершение исполнения Дракон-схемы. Кстати, реализация "параллельного исполнения" графа Ганта алгоритмически несложна.
67. Сергей Дудаков (Anything) 09.07.09 18:48
(65) В том-то и дело, что при варианте с "замкнутыми" ветками операторы return, break, continue можно изображать одним элементом, и без(!) всяких стрелок.

Потому что границы циклов и процедур легко обозреваются глазами и видно, куда перейдет управление.
68. Роман Тарасевич (tarroman) 20.08.09 15:38
(64) в свое время медитировал над нотацией, интуитивно понятной как пользователю, так программисту (я про проведение документов в 1С). Тем более, что поток данных в конфигурациях 1С строится строится по данным документа, т.е. в регистры информация попадает из документа + алгоритмические преобразования и доп. источники. Вот эту то связь и хотелось зафиксировать, чтобы на уровне между алгоритмами и функицианально-прикладном фиксировать логику работы систем (особенно когда работаешь с большими конфигурациями типа УПП 8.1, и комплексная конфигурация 7.7). Закончилось все шаблонными таблицами excel + были наброски системы проектирования бизнес-процессов на структуру данных тиражного решения (на 8-ке). А дальше все заглохло - проект зачах.

А вообще, задача визуализации/автоматизации процессов программирования всегда будет актуальной, особенно для людей, которые хорошо воспринимают графику (а визуалов думается большинство). Особенно это важно, когда нужно "перекинуть" мостик от проектирования к собственно адаптации/разработке решения на 1С.
71. dragonedit (Геннадий Тышов) 26.11.12 19:24
Ссылки на темы: язык Дракон и интегрированная среда ИС Дракон.

В.Д. Паронджанов, Как улучшить работу ума ...
Паронджанов В.Д. Язык Дракон. Краткое описание
Паронджанов В.Д. Занимательная информация
Паронджанов В.Д. Учись писать, читать и понимать алгоритмы. 2012г. В продаже.

Геннадий Тышов. ИС Дракон, Выпуск от 19.11.2012, выложено для скачивания бесплатно.

Ефанов С.Д. сайт Алгоритмический язык ДРАКОН Описание практики проектирования и программирования микроконтроллерных устройств в ИС Дракон. Имеется 4 видео фильма. Описание дано по состоянию ИС Дракон на январь 2012г.

ИС позволяет выполнять проектирование алгоритмов и выполнять программирование на ряде языков, в т.ч. на 1С.

Mixail Заголовок сообщения: Re: Как алгоритмизировать клиентские задачи для 1С ?
http://forum.oberoncore.ru/viewtopic.php?p=76096#p76096
Проектирование АРМ кассира.
Моя дебютная попытка использования Дракона для уяснения новой для меня задачки, формализации исходных требований, представления другим участникам проекта и т.д. и т.п. Я не программист ни по образованию, ни по должности. Моя задача именно проектирование и выдача спецификаций/заданий программерам. Проект не для 1С, но для 1С он бы ничем не отличался (знаю 1С77 по старой памяти). Пару диаграмм в картинках и весь комплект в .DRT в ZIP

С уважением,
Геннадий Тышов.
72. dragonedit (Геннадий Тышов) 02.12.12 07:42
Выпуск ИС Дракон от 02.12.2012 здесь
Возможно последний в 2012 году - году Дракона.

Перечень выпусков здесь

Прошу сообщать Ваши отзывы, замечания и предложения.
73. Андрей Акулов (DrAku1a) 02.07.13 03:00
Если охота поиграться в "программирование без программирования" - то рекомендую попробовать HiAsm... Идея там довольно классная. Хотя к 1С отношения не имеет...