1С + Дракон?

16.04.09

Разработка - Математика и алгоритмы

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

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

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

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

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

Почему?

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

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

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

 

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

 

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

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

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

См. также

Метод Дугласа-Пойкера для эффективного хранения метрик

Математика и алгоритмы Платформа 1C v8.2 Конфигурации 1cv8 Россия Абонемент ($m)

На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.

1 стартмани

30.01.2024    1753    stopa85    12    

33

Алгоритм симплекс-метода для решения задачи раскроя

Математика и алгоритмы Бесплатно (free)

Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.

19.10.2023    4415    user1959478    50    

34

Регулярные выражения на 1С

Математика и алгоритмы Инструментарий разработчика Платформа 1С v8.3 Мобильная платформа Россия Абонемент ($m)

Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.

1 стартмани

09.06.2023    7450    4    SpaceOfMyHead    17    

56

Модель распределения суммы по базе

Математика и алгоритмы Платформа 1С v8.3 Россия Абонемент ($m)

Обычно под распределением понимают определение сумм пропорционально коэффициентам. Предлагаю включить сюда также распределение по порядку (FIFO, LIFO) и повысить уровень размерности до 2-х. 1-ое означает, что распределение может быть не только пропорциональным, но и по порядку, а 2-ое - это вариант реализации матричного распределения: по строкам и столбцам. Возможно вас заинтересует также необычное решение этой задачи через создание DSL на базе реализации текучего интерфейса

1 стартмани

21.03.2022    7848    7    kalyaka    11    

44

Изменения формата файлов конфигурации (CF) в 8.3.16

Математика и алгоритмы Платформа 1С v8.3 Бесплатно (free)

Дополнение по формату файлов конфигурации (*.cf) в версии 8.3.16.

16.12.2021    4443    fishca    13    

36

Интересная задача на Yandex cup 2021

Математика и алгоритмы Бесплатно (free)

Мое решение задачи на Yandex cup 2021 (frontend). Лабиринт. JavaScript.

12.10.2021    8830    John_d    73    

46

Механизм анализа данных. Кластеризация.

Математика и алгоритмы Анализ учета Платформа 1С v8.3 Анализ и прогнозирование Бесплатно (free)

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

31.08.2021    7796    dusha0020    8    

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

(5) Визуализировать запросы можно. Я даже придумывал нотацию для описания запросов в 1С. Искал готовую, но не нашел, пришлось придумывать. Помогла один раз при разгребании головоломного запроса. :)
75. Alex_1066 28.11.19 12:01 Сейчас в теме
(10) Интересно было бы посмотреть... Может сохранилась? Иногда очень хочется иметь что-то типа того..
76. Anything 89 05.12.19 19:54 Сейчас в теме
(75) В голове точно есть. В виде документа - надо искать. Спасибо, что напомнили. Возможно, опубликую как-нибудь. :)
6. Душелов 4013 14.04.09 11:36 Сейчас в теме
7. keleg 327 14.04.09 11:53 Сейчас в теме
Дык, они уже неплохо визуализированы :-) Нафига изобретать велосипед еще раз? Сделать одну из иконок запросом и все... он же линеен по алгоритму.
8. Арчибальд 2706 14.04.09 13:06 Сейчас в теме
Владимир, а тебе редактор драконов скачать удалось?
9. PowerBoy 3350 14.04.09 13:50 Сейчас в теме
Автор интегрированной среды DRAKON – 1С программист 2-й категории Геннадий Николаевич Тышов :)
Очень интересно - почитаю. Спасибо.
11. Арчибальд 2706 14.04.09 16:55 Сейчас в теме
Поигрался с редактором. Все ж таки минимально серьезный алгоритм сразу теряется в квадратиках. Наверное, такая штука хороша при преподавании информатики - в плане развития систематического мышления и архитектурных приемов. В исходной предметной области, когда общаются инженеры с алгоритмистами - тоже, наверное, хорошо. Управленческий сценарий написать можно. А учет - вряд ли.
Но и перечисленное весьма обширно.
12. keleg 327 16.04.09 03:52 Сейчас в теме
(11) Не-а, не теряется. Если правильно все делать - разбивать на ветки и использовать свертку процедур, то любой алгоритм остается обозримым.
Но, конечно, экран желательно побольше чем 15 дюймов :-)
Я тут посмотрел как делаются компилеры на .net - семь экранов кода.
Думаю, попробовать сделать свой дракон-редактор простенький, который бы exe-шник компилил.
15. PowerBoy 3350 21.04.09 06:52 Сейчас в теме
(12) Был бы хороший ActiveX по рисованию схем, тогда можно было бы прикрутить его в обработке и формировать алгоритмические схемы уже в контексте конфигурации, а отдельный редактор не взлетит :)
17. keleg 327 21.04.09 09:55 Сейчас в теме
(15) ActiveX есть, но они только рисунок выдают, а хочется сразу код :-)
(16) И пусть. Я лучше учет буду ставить в организациях, это всяко интереснее, чем тупое кодирование глючных алгоритмов. Программированию - высокий уровень! :-)
28. PowerBoy 3350 21.04.09 12:41 Сейчас в теме
(17) А что у Вас за ActiveX? Можно на него глянуть?
29. keleg 327 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 Ответить
13. keleg 327 16.04.09 03:55 Сейчас в теме
Там очень прикольно обходятся некоторые 1С-проблемы. Например - длинные переменные, дающие необозримый код. Присваивание - в две строчки, сверху переменная, снизу выражение.
Использование для длинных переменных алиасов-псевдонимов, чтоб формулы писать.
14. keleg 327 16.04.09 04:39 Сейчас в теме
Добавил прямые ссылки на основную книгу и на дракон-редактор
16. MSensey 49 21.04.09 09:53 Сейчас в теме
Не боитесь, что вместо нас начнут бухгалтера дорабатывать конфигрураци? :)
19. Арчибальд 2706 21.04.09 10:02 Сейчас в теме
(16) Им давали КОБОЛ в свое время. И незаметно было, чтоб кто-то все бросил и программить начал.
20. keleg 327 21.04.09 10:04 Сейчас в теме
(16) Ну, значит КОБОЛ несовершенен. Excelом же они пользуются и вовсю!
18. MSensey 49 21.04.09 09:56 Сейчас в теме
Хотя, что боятся, ведь из 1с-ков хорошие бухгалтера получаются ))
21. Арчибальд 2706 21.04.09 10:05 Сейчас в теме
(18) Предлагали мне и главбухом, и финдиректором у себя. Влом, однако.
22. keleg 327 21.04.09 10:07 Сейчас в теме
(21) Не. Программировать это ведь не писать код, это ставить процессы, чтоб они потом независимо от тебя работали. Выработка технологий. А кто их исполняет - процессор или люди, это уже вопрос второй.
Все равно уже сейчас написание инструкций и обучение бывает не менее важно, чем само кодирование.
23. Арчибальд 2706 21.04.09 10:20 Сейчас в теме
(22)Согласен. Кодирование, скорее, отвлекает от программирования, чем составляет основу.
"Хорошим программистом становится только тот, кто своевременно уходит от пульта" (с) Э.Дейкстра.
24. keleg 327 21.04.09 10:23 Сейчас в теме
(23) Тут в обсуждении на партнерском форуме мысль возникла.
- Хороший программист думает сразу на языке программирования!
- Т.к. скорость думания зависит от совершенства языка (см. хотя бы алгебру до изобретения формул - ужас полный), значит можно реально повысить скорость программирования. В общем-то об этом книга и написана.
25. Арчибальд 2706 21.04.09 10:37 Сейчас в теме
(24) Вах, зачем нехорошим программистом меня обозвал? ;-)
Я на русском языке думаю. Ежели "Все видит, все понимает, а сказать не может" - это умный собак, а не прогрпммист.
26. artbear 1448 21.04.09 12:17 Сейчас в теме
(24) Мысль про "думает сразу на языке программирования" неверна, это давно известно :(
Хороший разработчик как раз не должен думать на языке программирования, он должен разрабатывать свои программы с использованием языка программирования.
Например, в 1С нет ООП, но можно придумать обходные пути.

ЗЫ рекомендую почитать книгу Макконелл "Совершенный код" - куча всего полезного.
На 1С мир еще не заканчивается, и есть куча способов обойти несовершенство конкретного языка программирования.
27. keleg 327 21.04.09 12:24 Сейчас в теме
Ну, про "думает на языке" говорил мой оппонент.
(задумался, на каком же языке думаю я? :-)
Прикол еще и в том, что в общем-то если убрать управляющие конструкции то большинство языков очень похожи.
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 6431 21.04.09 23:12 Сейчас в теме
Посмотрел материал. Интересно. Так и не понял, правда, чем указанное графическое представление отличается от блок-схем. Или блок-схему отсюда берут начало? Но не в этом дело. В сложных программах такое представление требует интеллектуальной, многоуровневой графической среды. Кстати, встречал такую среду, когда немного работал с ЧПУ. Был дорогущий пакет от Siemens, который позволял программировать полный цикл работы со станком именно по указанному принципу. Сперва программировался набор термов и лексем, применительно для описания предметной области и процессов станка. Затем составлялась блоксхема программы. После этого, можно было войти в любой участок блоксхемы и составлять программу, оперируя инженерными понятиями. Это мог делать уже не программист. В принципе, корректировать блоксхему тоже. Не скажу, что пакет был прост в эксплуатации. Описание занимало целый cd.
46. Арчибальд 2706 22.04.09 08:22 Сейчас в теме
(32) Принципиально не отличается. Добавлен набор эргомомиеских правил для повышения наглядности = снижения вероятности ошибок.
(34) В корне не согласен, что всякая задача изначально линейна (последовательна). Диаграммы Ганта - яркий пример "крупноблочных" параллельных задач. Примерно так: мы хотим получить результат (набор данных) А. Он зависит от данных Б, В, Г , т.е. А=F(Б,В,Г). Ниоткуда не следует, что мы должны получать аргументы последовательно, если конечно нет зависимости, скажем, В=G(Б,Г). Как только готовы исходные данные для блока (функции), мы можем запускать процесс, вычисляющий эту функцию. Процесс завершает свою работу прерыванием, сигнализирующим о готовности данных.
Программируем (мыслим) мы, конечно, последовательно, т.к. имеем всего один процессор. Система прерываний, однако, существует - это всякому известно - так что налицо квазипараллелизм мышления.
33. CheBurator 3119 22.04.09 00:22 Сейчас в теме
> Чтобы облегчить работу читателя и сделать алгоритм дружелюбным, разработчик дракон-схемы должен заблаговременно разрезать «длинную кишку» и разбить ее на смысловые части.
//
весь вопрос в том, что создание алгоритма и есть, по сути выделение смыслов, разбиение на процедуры/функции (реализующие эти смыслы)... готовый алгоритм красиво нарисовать - не сильно большая проблема (возмоно что при красивом рисовании смыслы будут упрощены/перетаосваны...)... ничего принципиально итересного не увидел.. тот же подход к проектированию "сверху вниз", который еще на вышке в 80-х годах усваивали... то, что разработана графическая удобная нотация - это да... а что еще???
34. CheBurator 3119 22.04.09 00:29 Сейчас в теме
> При этом разделение проблемы на N смысловых частей реализуется путем разбиения алгоритма на N веток.
...тихий хитрый ход, однако ;-)
разделение проблемы на ЭН смысловых частей как выполняется - паралельно, сорри, человек еще мыслить не научился (шизофреники разве), все мышление идет линейно, проблема "пробегается" (прикидывается варинт решения) по линейной неделимой ветке, и потом ее начинаем укрупнять и делить/паралелить на отдельные смысловые цепочки...
..имхо НЕЛЬЗЯ РАЗБИТЬ АЛГОРИТМ НА ЭН ВЕТОК. это разбиение на ЭН веток применяется к уже ГОТОВОМУ АЛГОРИТМУ (а не рождаются ветки в процессе разработки алгоритма) - только сначала этот алгоритм нариован ЛИНЕЙНО, "В КРУПНУЮ КЛЕТКУ", а дальше - разворачивай алгоритм до нужной степени детализации сверху-вниз - вычленяй отдельные смыслы - закидывай их в отдельные блоки/векти и т.д.
...
не втыкаю...
50. Паронджанов 22.04.09 15:46 Сейчас в теме
(34) Che Burashka пишет:
"..имхо НЕЛЬЗЯ РАЗБИТЬ АЛГОРИТМ НА ЭН ВЕТОК. это разбиение на ЭН веток применяется к уже ГОТОВОМУ АЛГОРИТМУ (а не рождаются ветки в процессе разработки алгоритма)"

Ответ. Вы не совсем правы. Алгоритм (а если есть поддержка, то и программа) разрабатывется в процессе работы с дракон-редактором. Ветки рождаются в процессе разработки алгоритма. Допустим, Вы нарисовали алгоритма из 7 веток. Посмотрели - не понравилось (или увидели ошибку). Что делать?
Ответ ясен - исправлять, добавлять новые элементы, убирать старые, менять в них надписи и т.д. Одним словом, надо думать и работать.
В итоге число веток в вашем алгоритме может измениться. В конце работы их будет не 7, а 9 или 10 или еще что-нибудь. А может быть, их будет 6, потому что В сделали вставку (вызов процедуры, а в этой процедуре, в свою очередь, вы сделали (примерно таким же способом 8 веток.
51. CheBurator 3119 22.04.09 15:57 Сейчас в теме
(50) конечно же, согласен. Вопрос упирается в технологию работы и проектирования. Я очень сомневаюсь, что СРАЗУ при наброске дракон-алгоритма непростой задачи будет рождено 7-15 веток.. скорее всего, либо сначала будет глобальный примитив, или 2-3 укрупненные ветки...
Вообще, мне конечно понравилось, думаю взять на вооружение.
Было бы очень интересно посмотреть ролик разработки реального какого-нибудь (или учебного примера) поразвесистей размером - наблюдение за живой работой зачастую дает возможность оценить перспективность предлагаемого решения (Дракона как сути) гораздо быстрее и правильнее, чем чтение кучи книжек...
35. CheBurator 3119 22.04.09 00:39 Сейчас в теме
простое соображение: так сложилось, что для нас привычнее читать/воспринимать слева-направо и сверху-вниз. Дракон предлагает перевернуть сног на голову: читать сверху-вниз и слева-направо. Возьмем средней величины алгоритм, развернем его в Дракон-нотацию (причем не сильно подробно!) - количество веток будет - МНОГО! притом, что в самой ветке - примитивов не так уж и много... получается гораздо выгоднее располагать ветки горизонтально! а не вертикально - возьмите тот же учетный алгоритм 1ски - да это сполшные если-то-иначе (ветки) и повестьте их как гирлянды в дракон-нотации - будут висет как серпантин и мешаться друг-другу......
хотя, конечно, может я и не в теме...
36. CheBurator 3119 22.04.09 00:49 Сейчас в теме
> Чтобы алгоритм был понятным, он должен быть стройным, красивым, упорядоченным, то есть эргономичным.
- опочки.. много чего намешано, без обоснования...
рассмотрим классическую задачу - "перключателя", требуется значение "флажка" перключать между крайними значениями (0,1/1,2) - типичная 1совская задача с пометками; для набора флажков 1 и 2, самое красивое решение: ф=3-ф; - оно стройное! красивое! и еще визуально упорядоченное! (не в пример конструкциям если). А вот понятен ли с ходу данный кусочек алгоритма...???
37. CheBurator 3119 22.04.09 00:54 Сейчас в теме
> До сих пор мы пользовались правилом «Чем правее, тем хуже». Однако здесь оно не имеет смысла. Поэтому на рис. 20 выбрано другое правило «Чем правее, тем больше скорость ракеты».
- предлагается на этапе разработки алгоритма выбрать правило некой оценки "сложности/красоты" алгоритма... а неизвестно, что взять за такой критерний!!! вот неизвестно с ходу - и все! сложность/красота алгоритма определяется желаемой конечной целью и способом ее достижения... зачастую алгоритм строится для получения конечного решения, а не для получения красивого решения (известная трилемма "дешево, качественно, быстро")
38. CheBurator 3119 22.04.09 00:56 Сейчас в теме
> Правило хорошей хозяйки. Если постараться, порядок всегда можно навести.
Именно! даже штатные блок-схемы при правильной их отрисовке и выбора нужной стпени детализации будут понятны и прозрачны ничуть не менее чем Дракон-нотация...
39. CheBurator 3119 22.04.09 01:01 Сейчас в теме
из всего этого пока что какой можно сделать вывод? да как обычно: перед тем как что-то начать делать - спланируй и нарисуй, причем желательно - понятно не только для себя, но и для "соседа". Что предлагает Дракон - вполне определенную нотацию (набор правил), позволяющую "рисовать" понятные алгоритмы (на начальном этапе)... - чем это отличается от того, что мы знали раньше - да ничем...
40. CheBurator 3119 22.04.09 01:08 Сейчас в теме
> считаются вредными и категорически запрещены.
..масло масленное, типа как "немножко беременна". Т.е. что предлагает Дракон - он вдалбливает в меня мысль "ДАЖЕ НЕ ДУМАЙ О ТОМ, ЧТОБЫ НАРУШИТЬ ПРАВИЛО" (в противовес тому, что в иных "местах", допустимо такое: "если данное решение эффективно, то для его реализации можно пренебречь правилами) - вот и все... за счет уменьшения количества допустимых действий повышается "эффективность" алгоритма, заключающаяся в его визуальной понятливости для его быстрой оценки. - Это есть премущество? в каких-то местах (и их наверное подавляющее большинстов) - да (это как наборы очень коротких инструкций процессора - для реализации сложного оператора не изобретают сложный и дорогой автомобиль, а сажают на велосипед кучу маленьких гномиков)
41. CheBurator 3119 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. CheBurator 3119 22.04.09 01:34 Сейчас в теме
Например: у меня есть процедура, выполняющая некие действия.
и у меня есть потребность выполнить нескольо иные действия, очень похожие на исходные. Из типологии Дракона мне следует "нарисовать" две разные ветки, ибо смысл _немного_ разный? или все-таки усложнить исходную ветку, реализовав требуемый мне функционал за счет добавления в исходную ветку несколько "если"....? где он, баланс...?
43. CheBurator 3119 22.04.09 01:38 Сейчас в теме
ну и сама оболочка Дракон (по ссылкам) слабовата все-таки.. при выходе задается вопрос "сохранить - да или нет" и отсутсвует такая часто требуемая опция как отказаться от выхода!!! и продолжить работу!!!! видать Дракон проектировали не на Драконе... (а вот я когда писал диплом - транслятор отлаживал на самом себе - ккак снежный ком шло - быстро и эффективно)...
44. CheBurator 3119 22.04.09 01:39 Сейчас в теме
Хотя если применить предложенный Дракон-путь, то тут достаточно эффектно могут получиться конструкторы нужных инструментов/результатов"... некое ООП...
45. keleg 327 22.04.09 08:07 Сейчас в теме
Спасибо, Че, за множество идей и комментариев.
Автор (Спасибо, Владимир! Я очень рад, что правильно понял Вас и мои выкладки совпали с вашими :-) очень правильно сказал, что силуэт это главное и единственное преимущество Дракона перед любой другой нотацией - текстовой или графической. А что главное в силуэте? Даже не ветки, они только иллюстрация принципа двумерности кода.
Любые сегодняшние блок-схемы это все равно одномерные структуры, параллельно-одномерность ведь тоже одномерность.
Создатель Дракона же "включил" в код двумерность изначально.
Возможно, это сделано не идеально. Но это ж не догма, это руководство к тому, чтобу думать и делать самому.
Дракон - первая цельная и полная система двумерного представления кода программы. И это, как минимум, ОЧЕНЬ интересно :-)
47. Арчибальд 2706 22.04.09 08:32 Сейчас в теме
+46 Конечно, способ решения задачи "цель -> способ" не очень характерен для учетных задач. Там "событие -> представление события" в основном используется. Исключение составляет, пожалуй, алгоритм закрытия периода - существенно ветвящийся.
48. keleg 327 22.04.09 09:31 Сейчас в теме
(47) А как пример автора из приведенной главы? Конечно, он несколько устарел с точки зрения бухгалтерии (НП давно уже нет) но как принцип?
49. Арчибальд 2706 22.04.09 09:41 Сейчас в теме
(48)Примеры красивые. И, наверное бухгалтеру понятны => полезны. Однако я бы рассматривал их скорее как иллюстрацию к комменту Че (45)
52. Паронджанов 22.04.09 16:05 Сейчас в теме
По-моему, кто-то сказал, что дракон не поддерживает параллельные процессы.

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

Желаю удачи вашей дискуссии.
53. Арчибальд 2706 22.04.09 17:55 Сейчас в теме
(52)НЕ поддерживает - не говорилось. Поддерживает - да, но не ориентирован на них. Или точнее: ориентирован на вычисления, управляемые командами. А для создания истинно параллельных вычислительных систем/алгоритмов характерна архитектура, при которой вычисления управляются данными. Сидит супервизор и обслуживает очередь (толпу) процессов и очередь (толпу) процессоров.
61. Anything 89 04.07.09 11:23 Сейчас в теме
(52) (56) (57) (60)

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

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

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

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

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


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

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

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

Ну, и что еще поразило - это Дракон-редактор. И поразило не в лучшем значении этого слова. Редактор должен быть удобным и мощным, тогда дракон-схемы могли бы получить большее распространение, хотя бы на концептуальном уровне. К сожалению, автор программы похоже никогда не видел графических редакторов и не знаком с современным программным обеспечением, иначе, я не знаю, чем объяснить такой самобытный пользовательский интерфейс.
65. keleg 327 06.07.09 07:23 Сейчас в теме
(61) Современные языки все же очень отошли от классической Виртовской схемы "один вход - один выход". return, break, continue - суть упорядоченные goto. А ведь есть еще и exception...
67. Anything 89 09.07.09 18:48 Сейчас в теме
(65) В том-то и дело, что при варианте с "замкнутыми" ветками операторы return, break, continue можно изображать одним элементом, и без(!) всяких стрелок.

Потому что границы циклов и процедур легко обозреваются глазами и видно, куда перейдет управление.
54. CheBurator 3119 24.04.09 01:29 Сейчас в теме
Читаю книжку описания языка.
Глава 3. Циклы
Рис.69 Пример цикла "пока" - напанятна!!!
в примере: 3 вертикальные линии, 4 излома.
а если примитивы цикла насадить на левый шампур (поменяв да-нет местами) - будет 2 вертикали и 2 излома - почему не так???
55. CheBurator 3119 24.04.09 01:32 Сейчас в теме
ага.. вроде дотумкал...
56. CheBurator 3119 09.05.09 06:31 Сейчас в теме
Жалко, что ветка заглохла... Исходный форум по Дракону - взял "на карандаш"...
57. keleg 327 12.05.09 03:45 Сейчас в теме
Я тут готовлю потихоньку большую статью про 1С в свете Oslo и Дракона.
Есть интересные мысли
58. PowerBoy 3350 12.05.09 06:26 Сейчас в теме
(57) Где бы почитать про эту "Oslo"?
60. Арчибальд 2706 14.05.09 09:11 Сейчас в теме
62. Anything 89 04.07.09 11:25 Сейчас в теме
Попробую еще раз изобразить рисунок... :)
Код
   |
 -<>-
|      |
|      |
 -----
   |
Показать полностью
63. Anything 89 04.07.09 11:40 Сейчас в теме
Кроме того, в Драконе не хватает формализованного представления данных.

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

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

А вообще, задача визуализации/автоматизации процессов программирования всегда будет актуальной, особенно для людей, которые хорошо воспринимают графику (а визуалов думается большинство). Особенно это важно, когда нужно "перекинуть" мостик от проектирования к собственно адаптации/разработке решения на 1С.
66. Арчибальд 2706 06.07.09 12:26 Сейчас в теме
(63, 64) Думается, для сложной программной системы следует использовать два типа графов.
Дракон-схема уместна при реализации "черного ящика", полученного при проектировании системы "от данных", т.е. модуля, реализующего получение набора выходных данных из набора входных.
При самом проектировании выделяются этапы преобразований входного (для системы) набора данных в выходной с выделением промежуточных наборов данных. Здесь может появиться параллелизм, а в целом граф будет подобен графу (диаграмме) Ганта. Событие - это готовность набора выходных данных модуля, т.е. завершение исполнения Дракон-схемы. Кстати, реализация "параллельного исполнения" графа Ганта алгоритмически несложна.
69. пользователь 29.06.10 12:11
Сообщение было скрыто модератором.
...
70. пользователь 29.06.10 13:04
Сообщение было скрыто модератором.
...
71. Геннадий Тышов 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. Геннадий Тышов 02.12.12 07:42 Сейчас в теме
Выпуск ИС Дракон от 02.12.2012 здесь
Возможно последний в 2012 году - году Дракона.

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

Прошу сообщать Ваши отзывы, замечания и предложения.
73. DrAku1a 1679 02.07.13 03:00 Сейчас в теме
Если охота поиграться в "программирование без программирования" - то рекомендую попробовать HiAsm... Идея там довольно классная. Хотя к 1С отношения не имеет...
74. AlexanderKai 09.01.17 10:50 Сейчас в теме
(73)
HiAsm то же самое программирование- for, ifelse. Только совершенно ненаглядное. В тексте гораздо проще ориентироваться, чем в HiAsm.
Дракон предлагает другой подход. Мы видим, что делает программа на человеческом языке. Интересует реализация, тогда смотрим код.
Плюс правила построения блок-схемы. Которые делают ее простой и наглядной.
В HiAsm в первом же примере мешанина из стрелок и блоков.
Оставьте свое сообщение