Автоматизация от А до Я. Практика применения языка ДРАКОН
Разработка - Математика и алгоритмы
Основные плюсы языка ДРАКОН для компании
Язык ДРАКОН используется для:
- описания бизнес-процессов компании и их аудит,
- разработки решений на базе 1С для их автоматизации,
- хранение кода этих решений,
- организация обучения сотрудников работе в рамках бизнес – процессов,
- запись и хранение инструкций пользователей – как работать в рамках бизнес - процесса.
Его основная изюминка в том, что в результате мы получаем полную бизнес-модель, которая не ограничивается только схемой и инструкцией для пользователя. В рамках этой бизнес-модели мы вместе с логикой разработки можем хранить и ее код – это дает нам возможность:
- проводить его аудит,
- вспомнить самому – что делали,
- передать другой команде программистов,
- обучать и поддерживать персонал Заказчика.
Чем язык ДРАКОН для описания бизнес-процесса лучше, нежели другие нотации?
- Он понятный – легко воспринимается визуально на практике.
- Он простой – там только три вида схем и около пяти реально используемых значков, которые позволяют описывать всю эту логику, не плодя очередные диаграммы.
- Ну и плюс ко всему – другие нотации не имеют средств, которые могут хранить код разработки.
И сегодня мы поговорим про технологию применения языка ДРАКОН при внедрении и последующей эксплуатации продуктов 1С на конкретном примере.
Теоретическая основа построения бизнес-модели
При подготовке к презентации я связывался с людьми, которые профессионально занимаются разработкой бизнес-моделей, в частности, с Кузнецовым Михаилом Анатольевичем. Он ведет проектную разработку в ARIS (это нотация, которая используется в основном при внедрении системы SAP).
Согласно его наработкам, бизнес-модель состоит из следующих компонентов:
- Смысловой уровень, который показывает цели и задачи компании.
- Эти цели спускаются вниз в виде управляющих документов, которые характеризуют процессы (этот блок обозначен здесь как «Модель процессов»).
- В этих процессах задействованы объекты бизнеса (иными словами, ресурсы);
- И все это сходится в отчеты (квартальные или за другой какой-то период), по которым топ-менеджмент понимает, достигли они каких-то своих поставленных целей или нет (здесь этот блок обозначен как «Панель управления»)
Такое представление бизнес-модели используется в основном для внедрения систем KPI, но также может использоваться и для других целей – в системах менеджмента качества и пр.
Пример использования ИС Дракон для выбора решения по автоматизации бизнес-процессов заказчика
Давайте перейдем от теории к практике. Для примера я взял рабочий проект автоматизации мебельной фабрики у нас в городе. В проекте участвует две стороны – Заказчик и Исполнитель. Заказчик – это владелец мебельной фабрики, а Исполнитель – это я. Мы с Заказчиком встретились и обсудили его задачи. В результате я составил «Дракон-схему» его модели бизнеса.
Посмотрим, что получилось.
Слева обозначена так называемая схема «Гном» (такой тип схем используется в основном для заметок), в которой описан каталог целей компании:
- Самый первый элемент на ней - это заголовок схемы.
- Далее, желтым цветом выделена миссия компании на рынке.
- А еще ниже находится элемент типа «Вставка», по которому происходит навигация по этим схемам.
Все это работает в среде ИС Дракон, автор живет в г. Северодвинске, – Тышов Геннадий Николаевич.
Сами схемы интерактивны: например, на элементе типа «Вставка» вы можете нажать стрелку «влево» и сразу попадаете на нужную схему. Так происходит декомпозиция. Это позволяет сложную логику разложить на более простые блоки.
Из каталога целей мы переходим к схеме типа «Силуэт», в которой записаны цели компании (тип схем «Силуэт» применяется для алгоритмов, состоящих из нескольких смысловых частей). Каждый заголовок (они выделены в красный овал) обозначает цепочку понятных для пользователя действий, которые расшифровываются в этой ветке.
Для каждой Цели Заказчика разрабатывается Концепция - укрупненный бизнес-процесс, который позволяет достичь этой Цели так, как это видится руководству. В первой ветке этой схемы мы будем работать с Целью, которая пытается усилить Вертикальную интеграцию: по схеме «Вставка» мы переходим к схеме Концепции вертикальной интеграции – нашему укрупненному плану, по достижению этой Цели.
На схеме Концепции вертикальной интеграции в виде конструкции «Цикл ДЛЯ» показан Жизненный цикл продаж (начало цикла – икона №5 и конец – икона №7).
- Обратите внимание, что на этой схеме есть не закрашенные области – элементы типа «Вывод» (они находятся между действиями, закрашенными зеленым цветом) – это управляющие документы, которые спускаются вниз (например, для отдела продаж это может быть план продаж на год, и т.д.).
- Соответственно, следующий за ним процесс руководствуется этим управляющим документом и т.д.
- Желтым цветом здесь обозначен наиболее важный этап цикла продаж – это так называемый «драйвер», основная задача, которую двигают все остальные задачи. Через эту «вставку» мы можем перейти на отдельную схему, детализирующую эту задачу-драйвер жизненный цикл производства мебели.
Итак, здесь показана схема жизненного цикла производства мебели:
- Сначала вы приходите в мебельный салон и заказываете кухню.
- Там вам ее обсчитывают,
- Потом изготавливают,
- Привозят к вам,
- Вы расплачиваетесь,
- Подписываете акт о принятых работах (согласны вы или нет), и всё.
Описав основной бизнес-процесс, который хочет автоматизировать заказчик, мы можем приступить к выбору подходящей конфигурации – той, у которой есть максимальный функционал, отвечающий нашим требованиям. Желательно, чтобы ее не нужно было дорабатывать – изменения могут быть, но они должны быть минимальными.
Как видите, при начале работы над проектом, язык ДРАКОН позволяет вам получить представление о бизнес-модели Заказчика, чтобы оптимально выбрать коробочный продукт для комплексного решения его задач, хотя мебель вы до этого не продавали и не собирали.
Подведем итог первых этапов нашего проекта-примера:
- Мы обсуждаем бизнес-процесс напрямую с Заказчиком (не программистом, не внедренцем) – он лучше знает, как у него продается и собирается мебель. И получаем информацию – что из себя представляет его бизнес.
- А потом, составив на основании его информации детализированную схему, уже легко проанализировать, что мы можем автоматизировать, а что нет.
- И на основании этого мы вместе выбираем коробочное решение для проекта.
Соответственно, язык ДРАКОН нужен на старте любого проекта внедрения программных продуктов компании 1С.
Пример использования ИС Дракон для поддержки и обновления программных продуктов на базе 1С
Какие преимущества в использовании языка ДРАКОН на этапе владения информационной системы на базе 1С, при ее обновлении и доработке?
- Если мы имеем бизнес-модель, мы можем её менять и развивать дальше.
- Уменьшается зависимость от персонала. Потому, что если от нас внезапно уходит человек и не успевает передать дела, мы можем взять «Дракон-схему» его действий и передать ее новому сотруднику, чтобы он с ней поработал и выучил. После этого человек готов встать в наши стройные ряды и дальше работает.
- «Дракон-схемы» позволяют описывать «реальные» технические задания, когда бухгалтеры уже обсудили, что им нужно, и сами составили для программиста окончательную схему: «мы хотим, чтобы делалось вот так вот».
- Плюс ко всему, так как схема хранит одновременно и код, и логику разработки, вы можете легко менять команды программистов, разработчиков – передавать им эти схемы.
- А поскольку там уже есть готовый код и список метаданных, которые были созданы для этой доработки, то на дальнейшие обновления вы тратите уже в разы меньше времени.
Давайте подробнее разберем тему обновления конфигурации 1С.
Представьте себе, вы поставили типовую конфигурацию, внесли в нее какие-то доработки по техническому заданию, а потом прошло обновление, и часть ваших доработок стерлась. Такое бывает, если в фирме, допустим, нет своего программиста, или он заболел, уволился. Приходится поднимать старый бэкап, смотреть, что он изменял в метаданных, восстанавливать эти изменения и т.д. Хорошо еще, если данные не есть.
Для упрощения обновления своих доработок я обычно составляю «Дракон-схему», например, такую, как показана на слайде. Здесь есть специальные переходы (элементы типа «Вставка»), которые интерактивно переносят меня на листы разработок. Они представляют собой дракон-схемы, где описаны:
- метаданные, которые создавались;
- логика разработки – для чего они создавались;
- и код который там выполняется.
Соответственно, когда я обновляю конфигурацию, я уже в тестовой базе могу пробежаться по этой дракон-схеме и проверить, весь ли внесенный мною функционал работает. Возможно, что-то из этого 1С уже сама реализовала, и значит, мне надо отказаться от каких-то своих доработок, и там уже продумать какие-то механизмы миграции, что-то сделать…
Пример использования ИС Дракон в процессе разработки
Переходим к третьей части. Зачем нужен язык ДРАКОН в процессе разработки?
- Я могу видеть логику создаваемого кода и проводить его аудит. С помощью «Дракон-схем» мы можем понять, что работает, а что нет, увидеть, что где-то надо убрать лишний код и т.д.
- Про смысловую передачу другой команде разработчиков я уже упоминал – зависимость от программистов уменьшается.
Чем составлять дракон-схем? Бумага, линейка, карандаш и ластик?
Схемы, которые я вам показывал, были сделаны в программе «ИС Дракон». Это, на мой взгляд, сейчас самый продвинутый инструмент для работы с этим языком. Простой и дешевый.
Еще есть «DRAKON Editor» и «Фабула».
Как дракон-схема хранит код и как использовать его при программировании в 1С.
Транслятор кода из ИС Дракон в Конфигуратор 1С использует метод программирования по GOTO. Не буду вдаваться в дискуссии по поводу правильно его использовать или нет. Статей в интернете на эту тему достаточно. Остановимся на том, что он есть. И вот как это работает.
Для наглядности немного расскажу о том, какие изменения мы вносили в программу 1С для Заказчика на примере оформления заказа производства мебели.
Как вы видите, в этой «Дракон-схеме» оформления заказа для каждого действия проставлены роли конкретных исполнителей. Например, указано, что первоначально заказ покупателя в конфигурацию УНФ вводит бухгалтер, а потом на основании этого заказа снабженец оформляет заказ на производство.
И тут в бизнес-процессе возникает «узкое место», я его выделил красным овалом. В чем суть? У заказчика в одной базе работает две разные фирмы, и материалы могут приходить на обе из них, а когда мы собираем кухню, нам нужно, чтобы эти материалы оказались на складе одной фирмы. Если это делать вручную, то кладовщик у нас должен сидеть, набивать расходы на недостающие материалы с одной фирмы на другую. Поэтому мы предложили заказчику сделать «волшебную кнопку», которая автоматизирует этот процесс.
На скриншоте показано техническое задание на разработку этой «волшебной кнопки».
Что она делает? Ищет недостающие товары фирмы-продавца, формирует на найденные позиции расходные и приходные документы. Дальше уже идет «вставка» для перехода на саму разработку с кодом.
Вот весь комплекс этих схем:
Каждая схема – это процедура или функция для модуля документа «Заказ поставщику». Именно они и автоматизируют эту «Волшебную кнопку».
Черные точки в заголовке схемы являются индикаторами того, что схема является процедурой и содержит код. В этих точках автоматически формируются заготовки, в которых описаны начало и конец процедуры (их текст показан на скриншоте внизу).
В «черных точках» конкретных действий пишется исполняемый код, в данном случае задаются параметры метаданных.
Так выглядит тип элемента «Цикл» (конструкции языка 1С «Для каждого … Цикл …»), зеленым цветом обозначены его границы (начало и конец). Между ними – исполняемый код для этого цикла.
А вот так выглядит тип элемента «Если». Вы здесь просто пишете условие: для «Да» такая ветка, для «Нет» – другая. А программа уже сама при генерации кода добавляет в модуль конструкцию «Если… Тогда» и метки, на которые происходит переход.
Для множественного «Если» используется другой тип элемента «Дракон-схемы»: «Переключатель».
В схеме мы также можем описывать изменения в метаданных. Например, на скриншоте слева, в схеме типа «Гном» указано, какие регистры сведений необходимо создать для работы этого функционала.
И, наконец, выделенный элемент – это результирующие доработки модуля. В его третьей «черной точке» я обычно пишу контактную информацию и суть разработки.
А четвертая «черная точка» – это уже сам итоговый код. Он собирается автоматически, и потом я его просто копирую из этого окна и вставляю в конфигуратор.
Как вы видите, сюда в виде комментариев также попадают и заметки, указывающие, в схеме под каким номером этот код находится.
Как производить отладку такого кода? У каждой схемы есть уникальный номер, который нигде не повторяется. Например, на скриншоте показано условие «Если» с номером 26.
И по комментариям в конфигураторе можно найти этот код. Как вы видите, здесь находится оператор «Перейти», который является аналогом GOTO в 1С. По нему производится переход на метку. Это не нужно писать вручную, все формируется автоматически.
Как вы видите, по метке 41 мы переходим на сообщение пользователю, которое возвращает текст ошибки, и после этого происходит конец процедуры. Так реализуется проверка логики разработки.
Работа с GOTO («Перейти» - в 1С) – это дело привычки. Мне нравится, потому что так нагляднее анализировать код в схеме после определенной практики.
Если вам не хочется работать с GOTO – просто вставляйте текст условия в действия, и он сформирует код в процедуре так, как вы его там написали.
Элементы схемы можно использовать просто как контейнеры для хранения текстовой информации кода.
Конечно, предварительную разработку я веду не в среде ИС Дракон, а в конфигураторе. У меня открыт конфигуратор, где я накидываю, например, логику запроса, который мне нужно разработать. Там доступен синтакс-помощник, автоподстановка кода, в пользовательском режиме можно запустить консоль запросов, все это протестировать, посмотреть, что у меня получается, какие параметры подставить. А после того, как у меня сформируются предварительные заготовки для каждого действия, я этот код из конфигуратора копирую и вставляю в нужные места схемы. Это особенно удобно делать, если вы работаете на двух экранах.
Программирование в ИС Дракон – как сбор паззла. В результате вы собираете всю мозаику, по которой видно код разработки целиком. Причем, код модуля, который автоматически получается на выходе, можно просто скопировать и поместить в конфигуратор. Протестировать, конечно, проверить, чтобы логика нигде не была нарушена.
Заключение
Язык ДРАКОН удобно использовать и для обучения персонала, и для общения с заказчиком, а также при разработке и поддержке конфигураций на 1С.
Что касается разработки, то работаю на многих проектах, где периодически приходится восстанавливать какой-то функционал, что-то доделывать, разбирать какие-то сложные чужие коды и т.д. И, сколько я работал, не встречал кода, написанного программистом, который я не смог бы описать на языке ДРАКОН.
ИС Дракон – это коробочный продукт с поддержкой разных языков. Я работаю с 1С, но там поддерживается также C++, язык микроконтроллеров, и некоторые другие языки. Сам продукт продается автором. Его полноценная версия весит очень мало и стоит недорого. Есть бесплатная демо-версия, которая может использоваться как просмотровая.
Поэтому, если нужно быстро провести внедрение 1С, обучить персонал работе в системе и поддерживать дальнейшую работу предприятия без лишних затрат, то советую воспользоваться этой технологией полностью или частично.
************
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года
Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Математика и алгоритмы Разработчик 1С 8.3 Абонемент ($m)
Данная внешняя обработка для платформы 1С:Предприятие реализует усовершенствованный алгоритм Левенштейна для вычисления схожести строк с учетом различных лингвистических особенностей русского языка. В отличие от классической реализации, этот алгоритм учитывает фонетические, визуальные и контекстные особенности набора текста.
1 стартмани
07.11.2025 6999 18 InFlach 17
Математика и алгоритмы Запросы Разработчик 1С:Предприятие 8 Бесплатно (free)
Рассмотрим быстрый алгоритм поиска дублей с использованием hash функции по набору полей шапки и табличных частей.
08.07.2024 9159 ivanov660 9
Математика и алгоритмы Разработчик 1С:Предприятие 8 1C:Бухгалтерия Россия Абонемент ($m)
На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.
1 стартмани
30.01.2024 16969 stopa85 12
Математика и алгоритмы Бесплатно (free)
Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.
19.10.2023 25228 user1959478 57
Математика и алгоритмы Разное 1С:Предприятие 8 1C:Бухгалтерия Россия Абонемент ($m)
Расширение (+ обработка) представляют собою математический тренажер. Ваш ребенок сможет проверить свои знание на математические вычисление до 100.
2 стартмани
29.09.2023 15714 maksa2005 8
Математика и алгоритмы Инструментарий разработчика Разработчик 1С:Предприятие 8 Россия Абонемент ($m)
Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.
1 стартмани
09.06.2023 25511 11 SpaceOfMyHead 20
Математика и алгоритмы Разработчик 1С:Предприятие 8 Бесплатно (free)
Три задачи - три идеи - три решения. Мало кода, много смысла. Мини-статья.
03.04.2023 17726 RustIG 10
Механизмы платформы 1С Математика и алгоритмы Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
В статье анализируются средства платформы для решения системы линейных уравнений в 1С. Приводятся доводы в пользу некорректной работы встроенных алгоритмов, а значит потенциально некорректного расчета себестоимости в типовых конфигурациях.
23.11.2022 16613 gzharkoj 17
1) Код пишется в конфигураторе, потом копированием переносится в схему. Какой в этом бизнес-смысл?
2) Произошло изменение в схеме, как оно отразится на изменении кода в конфигураторе?
3) Чем эти схемы лучше аналогичных многим известных диаграмм?
1) Код пишется в конфигураторе, потом копированием переносится в схему. Какой в этом бизнес-смысл?
Из практики: в конфигураторе я пишу куски и фрагменты, часто не связанные с собой. Например отлаживаю запросы и т.д.. В дракон-схеме, уже собираю их в нужный нам бизнес-функционал. :) В финале у меня код в конфигураторе и код в дракон-схеме идентичен.
2) Произошло изменение в схеме, как оно отразится на изменении кода в конфигураторе?
Никак, пока мы не скопируем весь текст целиком в модуль конфигуратора из схемы.
Прямой взаимосвязи нет между ИС Дракон и Конфигуратором.
3) Чем эти схемы лучше аналогичных многим известных диаграмм?
Дракон лучше воспринимается, меньше объектов, он генерит код для 1С - тоесть пригоден для программирования.
Конечно каждый сам выбирает для себя инструменты для решения поставленных задач. Я просто рассказал про свой. :)
Модуль на 2 тысячи строк содержит несколько процедур и GoTo не связывают строки всего модуля, а распределены по процедурам.
"GoTo является моветоном" - устаревший миф для программистов, повод для религиозных войн, то чему Вас кое как учили.
Goto, это основа в любой программе, до ассемблера доводится программа при трансляции в машинный код.
Зададимся вопросом - что главное в программе? Главным является полный комментарий, программный код может содержать ошибки, но они исправляются при отладке, выявляются при эксплуатации. При отсутствии же полного комментария и при изменении требований к программе, программу придется выкинуть и писать вновь.
Программа, созданная в ИС Дракон, гарантированно содержит полный комментарий с описанием логики в терминах прикладной области. Программный код не является 2-я тысячами строк модуля, он разбит и привязан к иконе (элементу) блок схемы. Нет необходимости обозревать 2-е тысячи строк модуля, а достаточно видеть блок схему в целом и разбираться с описанием отдельной иконы и реализующим функциональность программным кодом размером в 1..5 строк.
Строго структурированный текст смотрится, как лунная поверхность с глубокими кратерами. В нем уровень вложенности может быть большим, строка оператора "Если" оторвана от строки "КонецЕсли" так далеко, что надо прокручивать текст и связи между ними совсем не видно.
При ограниченном использовании операторов Перейти, Продолжить, Прервать, Возврат уровень вложенности в тексте значительно уменьшается. Смотрите .
Вернемся к Дракону.
Программист сам не пишет Goto. Он создает Дракон-схему (блок-схему) с иконами (элементами). Икона содержит несколько полей для различных комментариев и поле программного кода. Программный код модуля формируется путем сборки программного кода из икон и помещается программистом в конфигуратор. В программном коде уровень вложенности нет вложенности сведен до минимума.
Если нет инструмента, то это самое простое решение,
ИС Дракон можно скачать -
Дракон ведь не только средство программирования. Это еще универсальное средство общения.
Если вы в Драконе напишите программу, то можете показать ее заказчику, пользователю или начальнику, которые не понимают язык программирования, но они поймут как Ваша программа работает, почему она такая, как ее пользоваться - они все это увидят в Ваших блок-схемах.
Как результат - к Вам не будет вопросов.
Потом заказчик, пользователь или начальник будут обращаться к Вам уже с готовой Дракон-схемой - сделай пожалуйста. Вы же просто в нее впишите программный код.
ну правильно. в программе важен не код, а всякая писанина, которая ни черта не выполняется и в итоге не влияет на программу вообще. код , конечно, может содержать ошибки, но комментарии они , конечно, безошибочны, они всегда сами по себе обновляются с изменением программы и вообще содержат в себе кучу полезной информации, как например как зовут программиста, что он сегодня ел и куда ходил. а код бесполезная фигня, зачем читать код. что еще за чушь.
Вы же не читаете байт-код после того как написали код на 1С? Потому и не шизеете.
Но, по-моему, сейчас для этих целей более применим продукт 1С:СППР, который, как минимум, способен импортировать изменения структуры конфигурации, сделанные в конфигураторе, а в умелых руках вполне заменяет средства для коллективной разработки с хранилищами, ветвлениями, связи с требованиями, полуавтоматического создания документации и пр.
Изменение блок-схемы изменяет код, который генерит транслятор в итоге. Просто вы его вручную копируите в конфигуратор.
Чем лучше 1С:СППР? Не знаю. Не могу сравнить. 1С:СППР может переносить свой код в Конфигуратор - ну хорошо, еще один инструмент. Лучше когда их много, чем ни одного. :)
ИС Дракон закрывает в этом плане все мои потребности от документации до кода. Встречу хороший мануал по 1С:СППР - можно будет попробовать сравнить.
1. Рубеж "аналитик vs заказчик": аналитик, договаривается с клиентом - "так должно быть?" клиент соглашается, но не может проверить, какой результат будет получен в итоге?
2. Рубеж "аналитик vs разработчик": аналогично. Потом тяжба - "ну, я сделал, как на схеме"/"нет, на схеме заявка слева, а у тебя вверху"/"заявка слева платформой не поддерживается" и т.д.
То есть, графические схемы годятся для визуализации какой-то, достаточно малой части проекта и, по-моему, добавляют сложность на том этапе, где используются. Недавно встречал формулировку "доработать, согласно описанию бизнес-процесса", а это описание выполнено в схеме - как по ней вообще можно программировать, мне не понятно. Схема годится для выявления пользователей, которым нужно задать правильные вопросы и выявить первичные требования в "поведенческой" терминологии. А для этого гораздо больше подходит Gherkin, чем любой другой инструмент графического моделирования :-)
Использование ИС Дракон позволяет выполнять преобразование схем - выполнять декомпозицию, т.е. выполнять разделение на более мелкие. составные части.
AlexWhite, встреченная Вами формулировка вполне может быть отправной позицией для доработки.
1. Заказчик хочет выполнения бизнес-процесса с наименьшими усилиями. Если полученный в итоге процесс это обеспечивает - то все довольны. Дракон-схемы в итоге сводят все к "Инструкции пользователя" - то есть, скажем бухгалтера, чем меньше усилий занимает то или иное действие - при нужном результате, тем лучше. Аналитик - человек который должен придумать этот процесс и убедить или доказать это Заказчику. Мне это удается с помощью Дракона.
2. Если написанный функционал разработчиками - не выполняет дракон-схему "Инструкция пользователя" - то он не годиться. Тут тоже все просто. И проверено на практике.
Опять скажу, на практике проблемы встают в общем одинаковые у всех разрабов, на каком бы проекте они не работали и сколько бы они не занимались этим по времени. Просто я эти проблемы решаю дракон-схемами, и это работает. :)
Материалы для пользователей 1С подготовленный в ИС Дракон хорошо принимаются пользователями.
Конечно в презентации показан пример создания одной кнопки. Реальный проект состоит из большого количества дракон-схем. Обычно в дракон-схеме я указываю где этот код находиться, в каком объекте метаданных он расположен.
Для, тех, кто не знаком с Драконом, на мой взгляд необходимо сначала хотя бы пролистать книгу автора языка Паронджанова В.Д. "Дружелюбные алгоритмы...". После этого только можно идти дальше...
А сам пытаюсь (заставляю себя) описывать на нем логику разрабатываемого ПО.
Пока получается плохо из-за лени, и в т.ч. явной не очевидности данного процесса составления описания программы.
Т.е. пока ведешь разработку ты и так все помнишь и схема не нужна. А вот через 3-6-12 мес. когда (если)
буду дорабатывать свой же код, была бы очень полезна освежить память.
Но я не стремлюсь зайти так глубоко, как автор статьи. Считаю пока для себя достаточным делать функциональное описание программы, что бы был понятен смысл кода, процедур и их общая взаимосвязь.
Для, тех, кто не знаком с Драконом, на мой взгляд необходимо сначала хотя бы пролистать книгу автора языка Паронджанова В.Д. "Дружелюбные алгоритмы...". После этого только можно идти дальше...
Действительно, мы ничего не сказали о книгах Владимира Даниэловича Паронджанова.
Говоря о применении языка Дракон, надо быть знакомым с его книгами.
Все изданные книги и еще не изданные книги В.Д. Паронджанов выложил для свободного и бесплатного скачивания -
1. ~ 2000 г. История создания языка "ДРАКОН" -
2. 1998 г., 2000 г., 2008 г. Занимательная информатика ... -
3. 2001 г. Как улучшить работу ума. ... -
4. 2007 г. Почему мудрец похож на обезьяну, ... -
5. 2009 г. Язык Дракон. Краткое описание. -
6. 2010 г., 2014 г. Дружелюбные алгоритмы, понятные каждому. ... -
7. 2012 г., 2014 г. Учись писать, читать и понимать алгоритмы. ... -
8. 2016 г. Почему врачи убивают и калечат пациентов ...
Первый выпуск программы ИС Дракон выложен 06.04.2008, программа постоянно развивается с участием В.Д. Паронджанова и пользователей, рекомендуется в книгах 6,7,8. - , ,
Да, решение необычное, но вы никогда не пройдете 1С совместимо с данным кодом, пока генерация идет через GoTo. А зачем делать то, что в широкой массе не оценится и явно не будет плюсом к резюме.
Не зря же есть стандарты написания кода и стандартные инструменты, для того что бы любой другой, обладающий достаточной квалификацией человек, мог продолжить и ориентироваться в разработке.
Проблема с избыточностью условных операторов можно и нужно решать переосмыслением архитектуры.
Это мне напоминает один старый случай - один маленький но гордый украинский франч прокачал бухию еще на 7.7 и хранил кеш данных всей базы на локальном диске в виде DBF файла, и продавал данное изделие клиентам, можно так сделать - да запросто, но стоимость поддержки была в 5 раз выше.
В тех же названиях процедур и функций можно перейти к определению по F12, в GoTo как минимум еще 3 лишних движения в конфигураторе, пока нет EDT.
А самый сок, это когда вашу команду по тем или иным причинам отстранят от проекта и другой исполнитель будет явно недоволен.
Тогда не будут возникать проблемы при смене программистов или увольнении.
Я работаю на внутренних проектах Газпрома. Уж так сложилось. Координирую работу разных подрядчиков - и когда доходит дело до реальных задач, не было случая чтобы подрядчики что то не поняли или были не довольны кодом или бизнес-логикой в представлении дракон-схем. Чаще наоборот. Удается двигать даже очень "застарелые" задачи. :)
Что касается 1С совместимо. Это стандарт, а если он мешает продуктивной работе - то его надо менять. Для моего руководства важен результат. :)
В свое время я в составе никому неизвестного франча, который нанял более крупный франч, копался в конфе синхронизации контрагентов от Акселота, для того же Газпрома, которая до этого пережила только одно внедрение и из коробки не работала.
Опять же на работе в смежной с 1с области, я часто бывал в подразделении Транснефти, которое вело собственную разработку на САП, и видел блок схемы во всю стену(более 30 метров), по одному бизнес процессу, и ничего, все у них получалось .
Мое мнение достаточно компетентно?
Дракон в нынешнем виде не является серебряной пулей, да, интересно, но не более, возможно выльется и во что то большее. Но как быть с модной асинхронностью? Много комментариев тоже плохо.
Мне например проще, и я успешно это делаю, раскопать код по стеку, быстро передвигаться по F12 к определениям. Комментарии да, интересно, но при таком обилии мусорного текста проще алгоритм понять без комментариев. Вот например что значит строчка //***********Шампур? Зачем мне знать емейлы разработчиков, к тому времени как я туда полезу этих людей по этим емейлам возможно не будет. Абсолютные пути в комменнтариях, а если будет переезд всего и вся на другой диск, а то и на другой сервер?
Конечно я понимаю, что вы болеете за свое детище, но поймите правильно, если я, при всей наглядности языка ДРАКОН, сгенерирую данный код, меня в этот же день выгонят, потому что времени осваивать данный механизм всем остальным разработчикам нет, это неоправданные расходы как на обучение так и на поддержку, а потом вы проект свернете, по тем или иным причинам,и что делать с текущими наработками?
Задели за больное, а мы потом после одного такого продуктивного ..овнокод уже 6 месяц разгребаем. Да написано быстро, хорошо, но любое изменение требует перекопки просто всего ранее им же написаного, потому что для скорости и результата все сделано на костылях и граблях, строго в рамках решаемой задачи на текущий момент, механизм расширения функционала даже не предусматривался. Для того и введены стандарты что бы разработка была гибкой и поддерживаемой, а не сдавать механизм за механизмом, которые потом поддерживать сложнее, чем написать с нуля, перенести данные и снова сдать заказчику.
В ИС Драконе проект разбит на файлы Дракон-листов, изменения вносятся выполнением стандартных операций - создать, копировать, вырезать, вставить, заменить, переместить. Операции выполняются над графическими объектами.
Мне например проще, и я успешно это делаю, раскопать код по стеку, быстро передвигаться по F12 к определениям. Комментарии да, интересно, но при таком обилии мусорного текста проще алгоритм понять без комментариев.
При выполнении этой работы в ИС Дракон сегодня имели бы полностью комментированные, визуальные и обозримые Дракон-схемы для дальнейшего развития.
Надеюсь на дальнейшее развитие, и удачи Вам в Ваших начинаниях. Более того я давненько уже посматриваю за ДРАКОНом.
В моем понимании GoTo это вырубить оппонента с вертушки и переставить фигуры на доске в нужном себе порядке)
Может случиться все что угодно... Но если проект делался правильно, у Заказчика должна остаться документация, то есть искомые дракон-схемы. У нас в сейфе на флешке с журналом с ответсвенными МОЛ. Тут все зависит от подхода. Тоже самое с абсолютными путями. Где хранить файлы - это уже другая история.
Даже если вы решите внедрить не 1с а принципиально другое решение, дракон-схемы с бизнес-процессами у вас есть - уже готовые задания для разработчиков. Какая экономия средств и времени?
Один раз вы код раскопали по стеку, второй, после вас придет еще один "копатель"... а бюджет проекта не резиновый... . А я взял дракон-схему и вижу общую картину сразу, и другому передать могу, поправить могу более корректно, перестроить могу... все могу гораздо быстрей, потому что я и так вижу что хотел заказчик и как построен алгоритм и какие метаданные участвуют в работе.
Шампур - означает начало отдельной ветки в схеме "Силует".
Спасибо на добром слове и за обратную связь. :)
Есть такие понятия как сложности потока управления программы, советую почитать про граф управления и почему о нем надо знать программистам.
Притенении к Дракону (в аспекте 1С):
Неконтролируемый рост сложности потока управления: возможность возникновения паразитных переменных используемых в отдельных блоках, неконтролируемая информационная сложность кода и как следствие - неожиданные результаты связанные с производительностью + полное отсутствие понимания внутренних процессов, таких как управление блокировками и так далее.
Даже напрягаться не надо, чтобы написать "программу" которая будет отвечать всем критериям дракона, быть красивой и интересной, но вешающей машину, на которой она будет выполняться.
Притенении к автору:
Человек использующий go to в 1С, как в процедурном языке сразу перечеркивает любые доводы о профессионализме.
Но даже без учета написанного ранее: если вы говорите о том, что код с подобными конструкциями появляется автоматически, то будте любезны опишите процесс обратного построения схемы драконовской по сгенерированному им же коду. А то как понять, соответствует ли код схеме, а если схемы две, использующие пересекающиеся блоки, они-то корректно реализованы?А если вдруг надо внести правки в пересекающиеся блоки, а там go to?
Извините, слишком высокие накладные расходы, касательно 1С.
Дракон - помогает программисту, но не заменяет его. Если вы об этом. И у Дракона нет критериев - он описывает логику - это язык. А на языке можно ругаться а можно стихи писать. :)
Изначально код копируют из дракон-схемы в Конфигуратор, поэтому проверять соответствие не имеет смысла. Источник то дракон-схема и ее траслятор. Если вы пишите в конфигураторе и этот код в дракон-схеме не отражаете, то это на ваш страх и риск.
Как собрать код, если нет дракон-схем? По коментариям из схемы - они там подробные... .
А если я разбираю стандартный код в дракон-схему, а делаю я это часто, т.к. надо понять, что же там до меня написано. Разработчик не доступен, а его код надо разобрать. Тогда я трассирую и составляю дракон-схему с переносом кода. Вот и все. К концу трассировки становиться понятна логика, ошибки, и способы решения, локализованы вопросные моменты, связи между процедурами и метаданными... . В общем действенный способ.
Про goto писать не буду - мне оно не мешает. :)
Возможно, Вы имени ввиду Дракон-схему, отображающую процедуру, которая вызывается из разных мест. Тогда никаких проблем не возникнет, как и при любом использовании процедуры.
Ещё раз, код двух схем пересекаться не может?
Если я не могу описать информационную систему схемой целиком, а для, например, бухгалтерии предприятия это справедливо, то использовать один и тот же документ в двух разных схемах я не могу? А модуль, могу или нет?
Что страхов не было, надо перейти к освоению и наработке опыта, перешагните начального освоения.
Я гарантирую соответствие собранного (сгенерированного) программного кода Дракон-схеме и содержащему в ней написанному Вами коду.
Если есть сомнения, тогда проверьте, при наличии навыков программировать это не потребует много труда.
Поговорки отношения к программированию не имеют, простите.
Все, что вы написали в статье и комментариях подразумевает единичную реализацию некой информационной системы в вакууме, то есть ни о каком развитии системы, ветвлении версий, слияния версий и так далее речи вообще не идет. Это не плохо для бурана, когда один код генерируется один раз, но не для информационных систем, которые подразумевают развитие.
Для того, чтобы внести изменения в функционал мне необходимо используя комментарии собрать схему, переформатировать её потом опять сгенерировать и тестировать не конкретные изменения в конкретном блоке, а всю схему целиком, так? не слишком ли дорого?
(43)
То есть. для верификации программы первоначальной схемой все модули участвующие в схеме надо дублировать для каждой новой схемы, так? Или изменения в этих модулях не влекут изменения функциональности схем? Как решаются конфликты в смежном коде?
Все эти схемы и прочее используются в итерациях -- то есть изначально подразумевается развитие системы. Вся технология, что описана в статье служит для исключения вакуума разработки. То есть любой код и его изменение - это четко осознанная реализация бизнес-процесса программными методами.
Про пересечения - документы и модули можете конечно использовать сколько хотите, но в схеме вы указываете ссылку на этот документ или код. Которая и приводит вас к одной схеме. Без дублирования и повторений.
О докладе при заявке на конференцию:
1. Как выбрать оптимальную конфигурацию 1С для приобретения?
2. Как сформировать техническое задание для "реальных" процессов компании?
3. Как получить то, что заказывали, от программистов?
4. Как обучить сотрудников, "старичков" и быстро "запустить" "новичков"?
5. Как сэкономить на обслуживании и доработке?
6. Как не попасть в "зависимость" от программистов?
P.S: Все примеры рассмотрим на реальном проекте.
Основатель методики Scrum Джефф Сазерленд 21 апреля 2016г. в 22:54 рассказывает
Использование ИС Дракон позволяет работать по Scrum.
В частности: всегда видеть, выделить и заняться одной проблемой из всего множества:
Если делать одновременно несколько дел, получится и медленно, и плохо. Не поступайте так.
Если вы считаете, что вас это не касается, то вы ошибаетесь — это относится и к вам.
Я. знаю и помню Ваше желание видеть ДЕРЕВО.
Программа развивается и возможно будет ДЕРЕВО.
Сейчас же программа пригодна для практического применения.
Приходится выбирать: использовать сейчас или подождать, когда будет все желаемое.
В первом варианте, уже сейчас будет нарабатываться ваш опыт и опыт вашего окружения.
Да дерево хорошо. И дерево, надеюсь, будет.
Но и сейчас через "Файл-открыть папку" открываются все файлы в папке. То есть - храня файлы схем проекта в структуре папок файловой системы эта проблема частично снимается. Всегото и надо организовать папки на диске по отдельному проекту. Переключение между листами тоже худо бедно реализовано. :)
В противном случае (не обозревая схемы) - в этих goto быстро утонешь и скорость разработки характерная для 1С сойдёт на нет..
Второй вопрос - как эти схемы версионировать и, особенно, удобно сравнивать версии в истории изменений?
Жизнь, все же, показала, что лучше текстовых форматов пока ничего нет..
Надеюсь, даже, что управляемые формы скоро можно будет текстом писать - как HTML - и даже генерировать.. но это я, что-то, отвлёкся...
В общем, пока, по моему скромному, место Дракон-схем - разве что в документах по проекту - и то, если они действительно так понятны заказчикам..
Рисовать схемы и потом кодировать.. нет - быстрее, сразу кодировать.. а рисовать - вот разве что заказчику на подпись.
сначала разработать алгоритм в ИС Дракон, потом там же выполнить кодирование.
Если нет, тогда не лучше!.
ARIS и ИС Дракон имеют различные назначение и функциональность. Выбирайте.
В докладе хорошо показана технология использования ИС Дракон.
ИС Дракон настраивается для программирования на различные языки, в т.ч. на JavaScript.
хм, по моему я уже описывал довольно простой и понятный пример, но если Вам нужен код.. ))
итак, есть глобальная функция Выполнить(Текст), ей передается аргументом код текстом..
вот сам текст...
Если Ссылка.Пустая() Тогда Перейти ~Конец; КонецЕсли;
// тут отрабатываем ссылку если не пустая
Если Ссылка2.Пустая() Тогда Перейти ~Конец; КонецЕсли;
// тут отрабатываем ссылку2 если не пустая
Если Ссылка3.Пустая() Тогда Перейти ~Конец; КонецЕсли;
// тут отрабатываем ссылку3 если не пустая
~Конец:
Показатьсколько вложенных "Если" у вас получится? - а так простой и понятный код....
Многое зависит от организации личной работы, от готовности работать с заказчиком и пользователем, от ориентации на качество и на перспективу дальнейшего развития программного продукта.
Нет никаких ограничений передачи ИС Дракон другим лицам. Если же Вы, что то создали на ИС Дракон, то передавайте файлы Дракон-листов вместе с ИС Драконом. Программа в одном маленьком файле, не требует установки, не требует размещения в специальных папках на диске С:, может находится на одном из компьютеров в локальной сети для общего и одновременного использования несколькими пользователями.
"отдельную линию техподдержки" заводить не надо, в программе есть пункт меню "Справка/Письмо автору", есть пункт "Справка/Получить обновление".
Для покупателя Вашего ПО, получение от Вас ИС Дракон будет подарком, бонусом. Обратите внимание: программа называется "интегрированной средой" для пользователя, а не "интегрированной средой разработки" для программиста. Ваши Дракон-листы могут содержать сопровождающую информацию, содержать интернетовские ссылки, содержать имена различных файлов, содержать адреса эл. почты, создает каталог для размещения сопровождающих файлов, иконы могут содержать ссылки на сопровождающую информацию с ее контекстным открытием. Производиться открытие приложений в соответствии с установленной ассоциацией расширений имен файлов.
Автор статьи выбрал для 1С реальный инструмент, предложил работоспособную и прогрессивную технологию.
Посмотреть код? Как работать? :) Уточните вопрос пожалуйста.
Есть публикация с прошлого места работы.
Выкладывал для примера.
Или более большая работа, с доработкой закрытия месяца:
Если это не пойдет, дайте знать, пороюсь в архивах. Найду свежую внешку. :)
О практике программирования рассказано -
Комментарии Владимира Паронджанова |
|---|
| В промежуточный код надо смотреть только в одном случае.
Компилятор выдал сообщение о наличии ошибки, в промежуточном коде находим строку с ошибкой, от строки переходим к П-тексте Дракон-листа, корректируем в ней код. Маршрутный транслятор в ИС Дракон гарантировано обеспечивает трансляцию маршрутов Дракон-схемы в логику программного кода на языке программирования. В промежуточном коде смотреть, разбираться, проверять, править и т.д. операторы IF и GOTO не требуется. Для Вас исходником являются только Дракон-листы, не сохраняйте программные коды - это всего лишь промежуточный код. Программирование с применением ИС Дракон создает новый стиль программирования на который надо перейти. Вы не будете использовать операторы языка программирования связанные с логикой управления if, while, goto, case, break, continue. Будете использовать операторы объявления, вызова, присвоения, возврата, операции вычисления значения выражений. Дракон нужен не только для программирования. Он также нужен для составления с заказчиком задания, обеспечит проектирование проекта, обеспечит согласование Вашего проекта с заказчиком, позволит создать инструкцию для пользователя. Дракон обеспечить Вам возможность того, что Вас будут понимать заказчик, начальник, пользователь и Вы сами себя, когда вынужденно вернетесь к своей разработке. |
Не верю, что нельзя было генерировать что-то адекватнее, чем goto переходы. Но, повторюсь, если бы можно было гонять код из схемы и обратно - в принципе пофигу на метки
Преобразовать любой 1С программный код в Дракон-схемы очень сложно. Да и задача эта совсем другая.
Полагаю, что ценность не будет большой, т.к. проблемное описание в иконах программно не сформировать.
Полученный 1С программный код предназначен для выполнения.
Программный код смотрим в редких случаях: для нахождения иконы с ошибочным кодом.
Полученный 1С программный код предназначен для выполнения.
Программный код смотрим в редких случаях: для нахождения иконы с ошибочным кодом.
Справедливости ради замечу, что ДРАКОН используется в паре с Erlang - где вообще нет оператора goto, но видимо в этом случае идет сразу преобразование в байт-код виртуальной машины.
Или есть какое-то другое объяснение?
На этом форуме думаю есть пользователи, использующие язык ДРАКОН для работы с Erlang. Вполне возможно - пользуются другими программами-редакторами языка.
Кажется вот тут есть ответ на Ваш вопрос
Точнее тут
Подводя итог - GOTO есть во всех языках. Даже если вы думаете, что его нет, так как это оператор процессора)).
Гонять из кода в схему...
Если опустить все возражения типа "а зачем это надо?" то вот какая мысль есть по реализации этой идеи.
Исходя из того, что при конвертации схемы в код мы получаем текст с определенным строгим форматом. Тоесть у нас есть номера икон, начало и конец Шампуров и т.д. Что, теоретически позволяет нам написать алгоритм, который по такому форматированному тексту кода вполне мог бы нарисовать/сравнить дракон-схему.
Что бы разобраться с "Драконами" - лучше всего, как уже указывалось выше, предварительно ознакомиться с книгами например . Там приведено много примеров построения схем алгоритмов. В чем польза такого подхода - можно общаться с людьми предметной области (не программистами) на одном, понятном языке. А это уже не мало. Стоит ли использовать это в 1С? Наверное стоит. Тем более, что в этом форуме есть люди, которые этим пользуются. И большое им спасибо за то, что делятся своим опытом.
Ссылка для доступа и скачивания -
В папке выложены файлы для скачивания:
1. ИС Дракон, выпуск от 20.06.2016 - Dragon_2016_06_20.rar
2. Dragon_Изменения.txt
Прошу сообщать Ваши отзывы, замечания и предложения.
----
Из файла Dragon_Изменения.txt:
1. В схеме Гном добавлена икона Конец.
2. Функциональность П-,С-текста схемы перенесены в иконы Заголовок.
Для ранее созданных листов П-текст схемы переноситься в текст иконы Заголовок при загрузке.
3. При изменении текста икон Заголовок и Ветка, выдается предупреждение и устанавливаются закладки.
4. Для отображаемого текста икон, при вводе по клавише TAB вводится пробел. При этом в окне редактирования используется шрифт листа. Это позволяет (хотелось бы) в иконках Комментариях вводить текст таблиц с выравненными колонками.
6. Внесены другие незначительные изменения.
Доработки п. 3, 4 сделаны по предложениям программистов 1С.
Я понял. Это что-то вроде религии. Берём обыкновенные бизнес-процессы, добавляем элементы алгоритмических блок-схем, заворачиваем в красивую и убедительную
Человек - существо идеологически уязвимое, тем более, что советская эпоха привила среднему и старшему сверхдоверие к наукообразной подаче информации. А идеи, как известно не только "успешно овладевают массами", но и оставляют широкие прорехи в ее узких кошельках )
Есть, кстати, "такая же, но
Мысль, кстати. Возьму, например, заначку, схожу к знакомому психологу, попрошу (небезвозмездно) набросать заметки о пользе бега на костылях, закажу копирайтерам с десяток текстов, сеошникам раскрутку, открою юрлицо и готово: "ИННОВАЦИОННАЯ МЕТОДИКА ОЗДОРОВЛЕНИЯ ВЕРТИНСКОГО БЕГОМ НА КОСТЫЛЯХ" ) До 30% населения можно убедить в полезности чего угодно, методики давно и широко известны в узких кругах. Так что (далее следует слоган):
Бег на костылях уравнивает! Костыльный спорт в массы! Даёшь всемирную Костылиаду!
</SARCASM MODE>
П.С. А ведь всего лишь погуглил...
1. Обучающее видео:
2.ДРАКОН образование:
3. Семинар в ИСП РАН:
Визуальное программирование на языке ДРАКОН
На ХАБРе большая статья о языке Дракон и редакторах.
Александр Араптанов:
Здравствуйте дорогие коллеги, соратники, друзья и просто кому интересно.
Хочу описать свою практику работы с языком ДРАКОН. Что получилось, что не получилось, какие планы. Получить отзывы, критику, предложения, дельные и не очень мысли. Может кому пригодиться.
Вот список тем, которые я буду оформлять и выкладывать здесь по мере подготовки материалов:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Материал буду оформлять маленькими темами по приведенным выше заголовкам. Все цифры (не пропорции), названия и имена изменены - т.к. коммерческая тайна. Основано на реальных событиях.
Новый доклад заявлен на конференции 25-27 мая 2023, Санкт-Петербург.
Араптанов А.А. - доклад
ДРАКОН - практика разработки и поддержка 1С:ERP
командой подрядчиков и командой заказчика.
История одной задачи.
Примите участие во 2-м туре и проголосуйте за доклад Араптанова А.А.
Секция: - "Программная инженерия"
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 504530
Создание 19.04.16 17:06
Обновление 19.04.16 17:06
Просмотры 31761
Загрузки 0
Рейтинг
51
Комментарии 102
Код открыт Не указано
Рубрики Математика и алгоритмы
Кому Разработчик
Тип файла Нет файла
Платформа Не имеет значения
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
