Что является в программе движущей силой? Что порождает полезный результат? Конечно, алгоритм. Алгоритм создает тот эффект, ради которого написана программа. Алгоритм работает не один. Он работает совместно со структурами данных. Но именно алгоритмы составляют наибольшую часть программы.
Исторически сложилось, что алгоритмы в программах записываются в виде исходных текстов. Почти никто не ставит под сомнение, что текст - это и есть лучшее средство представления алгоритмов. Алгоритм кодируется внутри функций на языке программирования, например, C или JavaScript. Для тех, кто хочет разобраться в алгоритме с высоты птичьего полёта, предусмотрен псевдокод. Однако с текстом есть серьезные проблемы. Дело в том, что человек не оптимизирован под сплошной текст. Человек оптимизирован на восприятие графики. Текст - это относительно новое изобретение, а вот графическую информацию организмы обрабатывают уже миллионы лет.
Исходя из этого, логично было бы составлять алгоритмы в графическом виде. Посмотрите на инженеров. Они повсеместно используют чертежи. Чем же программисты хуже? Они тоже могли бы составлять чертежи алгоритмов. Некоторые здесь возразят: визуальное программирование якобы неэффективно. UML неудобен, а в блок-схемах легко запутаться. Уж лучше программировать традиционным способом - текстом. В структурном программировании есть хотя бы структура, и она обеспечивает порядок и единообразие. А кроме того, рисовать диаграммы долго и трудно. Печатать быстрее, чем рисовать.
Так что же, программисты обречены всю жизнь работать только с текстом?
Возможно, не всё так плохо. Существуют визуальные языки для представления алгоритмов, в которых тоже есть порядок и структура, например ДРАКОН, BPMN и LML Action Diagrams. Здесь мы рассмотрим визуальный алгоритмический язык ДРАКОН.
Как программировать на языке ДРАКОН
ДРАКОН не является самостоятельным языком программирования. Он работает в паре с текстовым языком, например, с JavaScript, Python или C++. Вместе с текстовым языком, ДРАКОН образует гибридный язык: ДРАКОН-JavaScript, ДРАКОН-Python или ДРАКОН-C++.
Программирование на гибридном языке происходит следующим образом:
- Рисуем ДРАКОН-схему.
- Внутрь икон помещаем небольшие кусочки кода на соответствующем языке программирования.
- Программа-транслятор преобразует ДРАКОН-схему в текстовый файл с исходным кодом.
- Этот текстовый файл включается в проект обычным образом.
Генерацию кода из диаграмм на сегодняшний день поддерживают несколько редакторов. Примеры в данной статье сделаны в DRAKON Editor.
Генерация кода из диаграммы
В диаграмме ДРАКОН берёт на себя управление потоком выполнения. Поэтому кусочки исходного кода в иконах не должны содержать ключевых слов типа if , else , switch , case , for , while и т. п.
Внутри икон должен быть только простой однозначный код: арифметические выражения, присваивания значений, вызовы функций, сравнения. А вот ветвление и циклы реализуются конструкциями языка ДРАКОН.
Генерация кода происходит следующим образом:
- Из каждой диаграммы создаётся функция.
- Название диаграммы становится названием функции.
- Параметры функции берутся из иконы «Формальные параметры», что расположена справа от названия диаграммы.
- Тело функции генерируется, исходя из структуры диаграммы и содержимого икон.
На рис. 1 представлен пример небольшой диаграммы на гибридном языке ДРАКОН-JavaScript и сгенерированный код на JavaScript:
Прямоугольник с текстом console.log(cat, dog)
на рис. 1 - это икона «Действие». Сколько кода можно поместить в одну икону «Действие»? Следует стремиться к тому, чтобы в одной иконе содержалась одна мысль. Иногда это одна строка кода, иногда несколько.
Сгенерированный код снабжён комментариями, в которых указаны номера икон. Находясь в редакторе, можно быстро перескочить к любой иконе, нажав Ctrl+I.
Рис 1. Диаграмма на ДРАКОН-JavaScript и сгенерированный из неё код.
Икона «Вопрос»
Для ветвления применяются иконы «Вопрос» и «Выбор».
Икона «Вопрос» (рис. 2) соответствует конструкции if-then-else .
Обратите внимание, что вместо слов true и false используются слова Да и Нет (можно переключить на Yes и No ).
«Истина» и «ложь» - это звучит эффектно, по-учёному. Однако человеку ближе знакомые с раннего детства «да» и «нет».
Надписи Да и Нет можно менять местами. Неизменным остаётся расположение выходов из иконы «Вопрос». Один выход идёт вниз, а другой - вправо. Ветвление в языке ДРАКОН всегда направлено вправо, поэтому выход из левой стороны иконы запрещён. Такая предсказуемость облегчает чтение диаграммы, так как читатель заранее знает, где искать выходы.
Ещё одной особенностью языка ДРАКОН является то, что для ветвления используется не полный ромб, а усечённый. Это экономит место на диаграмме.
Рис 2. Икона «Вопрос»
Визуальные логические формулы
Язык ДРАКОН делает ненужными логические операторы И , ИЛИ и НЕ , а также оператор «не равно». Сами логические операции, конечно, необходимы. Но вместо текстовых операторов ДРАКОН вводит визуальные логические формулы.
Чтобы получить визуальную логическую формулу, следует соединить несколько икон «Вопрос» (как на рис. 3).
Особенно приятно избавиться от отрицания. Отрицание не интуитивно, оно приносит ошибки и неудобство. Отрицание (логический оператор НЕ ) достигается в языке ДРАКОН перестановкой меток Да и Нет .
Текстовая запись логических выражений, безусловно, более компактна. Однако визуальные формулы легче для прочтения. Каждую из возможных комбинаций значений операндов можно проследить пальцем.
Рис 3. Визуальные логические формулы
Цикл со стрелкой
Для обозначения обычного порядка выполнения в языке ДРАКОН стрелки не нужны. Следующая икона всегда находится внизу. Стрелка требуется только тогда, когда поток выполнения должен прыгнуть вверх по диаграмме. Такой прыжок вверх означает цикл. Следовательно, стрелка в языке ДРАКОН есть признак цикла. При беглом взгляде на ДРАКОН-схему стрелки сразу заметны. А значит, сразу видны и циклы. Это серьёзное преимущество ДРАКОНа по сравнению с другими графическими языками. Циклы не приходится выискивать.
Итак, если соединить икону «Вопрос» со стрелкой, получится цикл. Это аналог конструкций while
и do-while
. На рисунке 4 показаны несколько видов циклов со стрелками.
Икона «Вопрос» в цикле со стрелкой проверяет условие выхода из цикла. Конечно, вместо одной иконы «Вопрос» может быть несколько. Тогда за выход из цикла отвечает визуальная логическая формула.
Рис 4. Стрелочные циклы
Икона «Выбор»
Икона «Вопрос» содержит логическое выражение, то есть может принимать два значения: Да и Нет . Типичный пример - сравнение двух объектов. Если же нужно сравнить некое выражение с несколькими значениями, применяется икона «Выбор» (рис. 5). Это соответствует конструкции witch-case .
Значения, с которыми будет сравниваться выражение в иконе «Выбор», помещаются в иконы «Вариант». Если в самом правом варианте нет текста, это означает «все остальные значения». Такой пустой вариант похож на ключевое слово default
внутри оператора switch
.
Самый правый вариант может окончиться стрелкой, которая ведёт вверх. В таком случае мы опять имеем дело со стрелочным циклом. В таком цикле за условие выхода будет отвечать икона «Выбор», а не «Вопрос».
Рис 5. Икона «Выбор» и иконы «Вариант»
Икона «Цикл ДЛЯ»
Вместо циклов for и foreach в ДРАКОН-JavaScript применяется икона «Цикл ДЛЯ». Икона «Цикл ДЛЯ» (рис. 6) может быть нескольких видов.
Если после ключевого слова foreach и перед точкой с запятой находится одна переменная, то генерируется код для итерации по массиву. В переменную будут помещаться элементы массива (но не их индексы).
Если после ключевого слова foreach стоят две переменные, DRAKON Editor поймёт, что требуется итерация по свойствам объекта (записям хэш-таблицы). Только собственные свойства объектов попадут в перечисление.
Третий вариант цикла подразумевает наличие трёх выражений, разделённых точками с запятой. Это традиционный цикл for , характерный для языков C и Java.
Из цикла под управлением иконы «Цикл ДЛЯ» возможен досрочный выход при помощи иконы «Вопрос» или «Выбор». Такой выход примерно соответствует ключевому слову break
.
Рис 6. Различные виды иконы «Цикл ДЛЯ» в ДРАКОН-JavaScript
Только один вход в цикл
В языке ДРАКОН на циклы наложено ограничение. Каждый цикл может иметь только один вход. Цель этого ограничения - обеспечение читаемости. Это ограничение удерживает ДРАКОН в рамках структурного программирования, как его описывал Дейкстра.
Несколько выходов из цикла - это допустимо, но вход должен быть только один. На рис. 7 показаны циклы, у которых есть по два выхода. Это разрешено. На рис. 8 представлены примеры запрещённых циклов. Запрещённых потому, что в них можно войти разными путями.
Однако не стоит заучивать наизусть внешний вид этих запрещённых циклов. DRAKON Editor автоматически обнаружит такие циклы и выдаст ошибку.
Рис 7. Разрешённые циклы, у которых по два выхода
Рис 8.
Запрещённые циклы, у которых по два входа
Отличия от текстового структурного программирования
Как видим, иконы и макроиконы языка ДРАКОН имеют соответствие со стандартными конструкциями текстового структурного программирования. Однако есть и различия. Текст, пусть даже с индентацией, - одномерный объект. А диаграмма - двумерный. В диаграмме появляется дополнительная степень свободы, которая повышает выразительность. Попробуйте, например, на текстовом языке программирования без повторов и goto изобразить такой алгоритм, как на рис. 9.
Несмотря на дополнительную по сравнению с текстом свободу, ДРАКОН всё же не позволяет удариться в анархию. Его правила достаточно суровы, чтобы не допустить беспорядка. ДРАКОН предоставляет разумный компромисс между гибкостью и строгостью.
Рис 9. Алгоритм, который трудно изобразить только текстом
Преимущества графического языка
Язык ДРАКОН имеет интересную судьбу. Его основные принципы были заложены ещё самим Дейкстрой. Нынешнюю свою форму ДРАКОН приобрёл в недрах российской космической отрасли. Примечательно то, что правила языка ДРАКОН не возникли случайно. Они были сначала обкатаны в фокус-группах, а потом отточены в реальных космических проектах.
Так в чём же именно заключаются сильные стороны ДРАКОНа?
Начнем с того, что ДРАКОН - это графический язык. А у графического языка имеются фундаментальные преимущества по сравнению с текстом.
Во-первых, мысли не размазаны случайным образом по строкам, а заключены внутри квадратиков, или икон. Одна мысль - один квадратик. Разные мысли не склеиваются в одно месиво.
Во-вторых, путь через алгоритм можно проследить пальцем (или взглядом). После if не нужно искать else . Идите по линии и попадёте в нужный квадратик. Не требуется бегать глазами по исходному коду в поисках ответа на вопрос: что же было дальше?
А ещё у диаграмм есть одно почти волшебное свойство. Бывает, смотрит человек на диаграмму, и вдруг приходит какое-то дополнительное понимание. Становятся очевидными ранее невидимые связи. С текстом так бывает редко.
Особые эргономические правила
Но ДРАКОН - это не просто диаграммы, это тщательно продуманные диаграммы. ДРАКОН-схемы воспринимаются легче, чем обычные блок-схемы. Это обеспечивается особыми эргономическими приемами. Вот некоторые из них.
- Пересечения линий запрещены. Вообще. Пересечения заставляют наш зрительный анализатор подозревать, что линии касаются, а значит, каким-то образом связаны. Эти подозрения создают дополнительную умственную работу. Ненужную работу следует отбросить.
- Начало содержит название алгоритма и всегда расположено в левом верхнем углу диаграммы. Поэтому начало даже и искать не надо. Оно есть там, где обычно.
- Диаграмма имеет только один конец. Что бы ни случилось по дороге (кроме исключений), мы всегда придём в конец.
- Разрешены только прямые линии. Никаких кривых и изгибов, а также ненужных изломов.
- Разрешены только строго вертикальные и строго горизонтальные линии. Наклонные линии запрещены. Пояснение для любителей математики: ДРАКОН-схема представляет собой плоский прямоугольный граф (манхэттенский граф). Зрительный аппарат человека моментально схватывает объекты, соединённые прямыми ортогональными линиями. А вот отслеживание того, куда приведёт «кривая американской мечты», требует от читателя дополнительной концентрации.
- ДРАКОН-схема исполняется сверху вниз. Данное правило позволяет избежать необходимости лихорадочно сканировать глазами диаграмму в поисках следующей иконы. Следующая икона всегда внизу. Вход у иконы сверху, а выход снизу. Раз мы знаем где следующая икона, то и стрелки не нужны. Достаточно простых линий. Стрелки возле каждой иконы - это зрительный шум. Сняв со стрелок задачу соединения икон, можно возложить на них особую миссию. В ДРАКОНе стрелка означает цикл.
- Ветвление происходит только вправо. Это огромное подспорье в разрезе предсказуемости и единообразия.
- Иконы, находящиеся на одной вертикали, должны иметь одну и ту же ширину. Это даёт ощущение принадлежности икон к единому целому. Когда ширина у всех одна, и нет икон-выскочек, глаз легко и свободно скользит по диаграмме.
Приведенные выше правила имеют громадную практическую ценность. С одной стороны, они призваны обуздать безумство художника. Создать запутанную диаграмму с ними сложнее. С другой стороны, они привносят в диаграммы узнаваемость. Диаграммы становятся понятными не только их авторам.
Диаграммы на рис. 10 и 11 демонстрируют эргономические приёмы языка ДРАКОН на реальных примерах.
Рис 10. Эргономические приёмы языка ДРАКОН на примере
Рис 11.
Ещё один пример диаграммы на языке ДРАКОН
Помимо эргономических приемов, язык ДРАКОН имеет уникальные особенности, которых больше нигде нет.
Чем правее, тем хуже
ДРАКОН имеет средство для изображения happy path , или царской дороги . Царская дорога - это наиболее удачный путь через алгоритм. В некоторых алгоритмах понятия «удачный/неудачный», «хороший/плохой» не применимы. В них царская дорога показывает наиболее ожидаемый путь. Царская дорога проходит по вертикали, расположенной в левой части диаграммы. Эта вертикаль называется шампур. Менее вероятные и менее удачные сценарии, а также обработка ошибок помещаются в правой части диаграммы. Причём чем ситуация хуже, тем правее она должна быть расположена. Хорошим стилем является размещение кода, который бросает исключения или возвращает код ошибки, справа на диаграмме.
Общая судьба
Иногда бывает так, что на разных путях через алгоритм надо осуществить различные, но каким-то образом связанные действия. Например положить разные значения в одну переменную. Общая судьба - это когда связанные действия сидят на разных вертикальных линиях, но на одной горизонтали.
Рис. 12 показывает шампур с царской дорогой, а также применение приёма «общая судьба».
Рис 12. Царская дорога и общая судьба
Силуэт
Силуэт - это настоящий бриллиант ДРАКОНа. Силуэт позволяет разбить диаграмму на логические части. В программировании для этого обычно используют декомпозицию при помощи подпрограмм. Подпрограммы - действенный метод. Но иногда хотелось бы расположить подпрограмму визуально недалеко от основной программы, а также избежать возни с передачей параметров и возвратом значений. Для этих целей отлично подходит силуэт. Ещё одно применение силуэта - конечные автоматы. Но об этом мы поговорим в другом месте.
Случается, что алгоритм не получается разложить на плоскости так, чтобы не было пересечения линий. В таком случае, в зависимости от ситуации, применяют либо декомпозицию при помощи подпрограмм, либо силуэт.
Силуэт состоит из нескольких малых диаграмм, соединённых в один целостный блок. Эти малые диаграммы называются ветками силуэта. Наверху каждой ветки расположена икона «Шапка ветки», внизу - икона «Адрес». В шапке ветки помещают название данной ветки, а в адресе указывают название следующей ветки. Названия веток расположены на одной горизонтальной линии в верхней части диаграммы. Благодаря этому, можно ухватить суть алгоритма, пробежав лишь по шапкам веток. Силуэт отвечает на три царских вопроса:
- Как называется проблема?
- Из скольких частей она состоит?
- Как называются эти части?
Рассмотрим пример на рис. 13. Вот ответы на царские вопросы:
- Как называется проблема? Упорядочить связанный список.
- Из скольких частей она состоит? Из четырёх.
- Как называются эти части? Построить матрицу связей. Проверить наличие циклов. Пройтись по матрице связей. Завершить.
Рис 13.
ДРАКОН-схема «силуэт»
Силуэтный цикл
Ветки силуэта следует упорядочивать слева-направо. В некоторых случаях необходимо выполнить какую-то ветку или группу веток несколько раз. Такая конструкция называется силуэтный цикл. Если икона «Адрес» указывает на свою собственную ветку, либо на ветку, которая расположена левее, её следует пометить специальной меткой. Такую же метку нужно поставить на соответствующую икону «Шапка ветки» (см рис. 14). Назначение метки - сделать силуэтный цикл заметным.
Рис 14. Силуэтный цикл и метки
Соединение веток силуэта запрещено
Соединения двух веток силуэта (как на рис. 15) запрещены. Каждая ветка внутри силуэта должна быть самостоятельной.
Рис 15. Соединение веток силуэта запрещено.
Размер диаграмм
Во время программирования на языке ДРАКОН возникает вопрос: какого размера должны быть диаграммы? Ответ такой: чем меньше, тем лучше. Чем меньше объектов на зрительной сцене, тем понятней. В текстовом программировании есть такой ориентир: хорошо, если вся функция целиком помещается на экране. Похожий совет можно дать и для ДРАКОН-схем. Избегайте огромных диаграмм. Когда весь алгоритм виден полностью, его гораздо легче понять.
Для программирования на ДРАКОНе лучше иметь большой монитор. Хотя бы 1080 точек в высоту. Тогда не придётся искусственно укорачивать ДРАКОН-схемы.
ДРАКОН-схема силуэт должна помещаться на экране по высоте, но не обязательно по ширине. Диаграммы силуэт могут быть довольно широкими, гораздо шире, чем 2000 пикселей. Это нормально. Не обязательно видеть одновременно все ветки силуэта. Главное, чтобы та ветка, с которой вы сейчас работаете, была полностью видна на экране.
Критика программирования на ДРАКОНе
Рассмотрим основные направления критики программирования на ДРАКОНе и попытаемся дать на них ответ.
- «ДРАКОН-схемы занимают больше места на экране, чем текстовые программы.» Это правда. Но надо иметь в виду, что задача ДРАКОНа - показать сложность, как она есть. Читатель программы не должен распаковывать в голове сложные структуры. Они должны быть показаны ему в явном виде.
- «Простые алгоритмы лучше смотрятся в текстовом виде». Возможно. Hello world на любом языке смотрится элегантно. Но в реальной жизни не всё просто. Как только появляется хотя бы один if , вложенный в другой if , ДРАКОН выигрывает.
- «ДРАКОН не имеет средств для отображения исключений (exceptions).» Такая проблема есть. Исключения были недавно добавлены в язык ДРАКОН, но не все реализации их поддерживают. Пока реализации не подоспели, можно писать блоки try/catch на соответствующем языке программирования.
- «ДРАКОН-схемы долго рисовать.» В специализированных редакторах рисовать ДРАКОН-схемы гораздо легче, чем, например, в Visio. А в некоторых из них рисовать стало почти так же просто, как писать.
- «Отсутствует инструменты для diff и merge.» Это, к сожалению, так. При работе с системой контроля версий сравнивать приходится сгенерированные исходные файлы.
- «Отсутствуют средства отладки ДРАКОН-схем.» Это правда. Но можно отлаживать сгенерированный код. В нём есть метки, которые указывают, к какому месту в диаграмме относится данный кусок кода.
Обзор языка дракон
На рисунке 16 представлен обзор языка ДРАКОН.
Рис 16. Обзор языка ДРАКОН
Инструменты для работы с языком дракон
Самой первой реализацией языка ДРАКОН была система ГРАФИТ-ФЛОКС (рис. 17). ГРАФИТ-ФЛОКС создавалась в 1986-1996 гг. специалистами ФГУП НПЦ АП им. Пилюгина под руководством В.Д. Паронджанова. Эта среда предназначалась для проектирования систем управления ракет-носителей и космических аппаратов.
ГРАФИТ-ФЛОКС - закрытая разработка, поэтому о ней известно относительно немного. Список космических аппаратов, созданных с применением ГРАФИТ-ФЛОКС, можно посмотреть .
В начале 90-х годов был создан ещё один ДРАКОН-редактор. Разработка велась в Институте прикладной математики имени М.В. Келдыша под руководством Л.К. Эйсымонта. Редактор Эйсымонта (рис. 18) можно скачать и запустить, но он более не поддерживается. Редактор написан под MS DOS, поэтому для запуска на современных компьютерах может потребоваться DOSBox.
В 2008 году увидел свет редактор ИС Дракон от Геннадия Тышова (рис. 19). ИС Дракон активно поддерживается и развивается. В ИС Дракон реализована генерация программного кода из диаграмм. Одной из интересных возможностей ИС Дракон является возможность помещать в одной иконе код на языке программирования и описание на естественном языке. Безусловное достоинство ИС Дракон - так называемое «исчисление икон». Исчисление икон - это способ редактирования, который помогает пользователю рисовать диаграмму и гарантирует, что диаграмма не нарушит правила языка ДРАКОН. Среди недостатков ИС Дракон можно отметить нестандартный интерфейс пользователя и некоторые неудобства при генерации кода. ИС Дракон - коммерческий продукт.
DRAKON Editor - ещё один современный ДРАКОН-редактор (рис. 20). DRAKON Editor был разработан группой энтузиастов под руководством Степана Митькина. DRAKON Editor не поддерживает исчисление икон. Это означает, что ДРАКОН-схемы собираются в нём вручную из примитивов, как в векторных графических редакторах. Но зато интерфейс пользователя в DRAKON Editor максимально прост. Он построен по более привычной схеме, чем ИС Дракон. Основным преимуществом среды DRAKON Editor является удобство программирования и генерации кода. DRAKON Editor поддерживает несколько языков программирования, включая C, C++, C#, Java, Processing, JavaScript, Lua, Erlang, Python, Tcl, Verilog, AutoHotkey, D и Go. Для некоторых языков имеется возможность генерировать конечные автоматы. Поддерживаются правила для экспертной системы nools. Реализовано подмножество языка УТОПИСТ Э. Тыугу. DRAKON Editor имеет открытый исходный код.
Интересное применение для языка ДРАКОН придумал Олег Гарипов в своём проекте Integrator CodeView. CodeView позволяет визуализировать имеющийся код в виде взаимосвязанного набора ДРАКОН-схем. Особенность Integrator CodeView заключается в том, что визуализируются не отдельные методы, а проект целиком, включая граф вызовов, стек и т. п. Integrator CodeView уникален ещё и тем, что он наглядно показывает не только алгоритмы, но и данные. Движок визуализации данных в системе Integrator работает совместно с ДРАКОНом.
DRAKON Editor Web - это коммерческое облачное решение на базе языка ДРАКОН. DRAKON Editor Web предназначен для технических заданий, бизнес-процедур и чек-листов. DRAKON Editor Web никак не связан с DRAKON Editor и не поддерживает генерацию кода из диаграмм. Среди плюсов DRAKON Editor Web следует отметить удобный редактор, совместную работу и поддержку мобильных устройств.
Рис 17. ДРАКОН-схема в системе ГРАФИТ-ФЛОКС
Рис 18.
ДРАКОН-редактор Эйсымонта
Рис 19.
Программа с пояснениями в ИС Дракон
Рис 20.
DRAKON Editor
Выводы
Подведем итоги. ДРАКОН - закалённый в космосе практический язык. Он привнёс в блок-схемы структуру, порядок и единообразие. Предсказуемость и опрятность ДРАКОН-схем приводят к тому, что визуальное программирование работает .
Опыт реальных проектов показал: программировать на ДРАКОНе можно. С одной стороны, ДРАКОН более выразителен, чем текст. С другой - повышает читаемость программ. А кроме того, программы в виде ДРАКОН-схем выглядят, ну прямо как из космического корабля пришельцев (хотя многое зависит от цветовой схемы). Лично я легко перешёл на ДРАКОН. Неудобно бывает, когда наоборот, приходится иногда программировать в традиционном текстовом стиле.
Добавить метки
Язык ДРАКОН используется для:
- описания бизнес-процессов компании и их аудит,
- разработки решений на базе 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 года
Приглашаем вас на новую конференцию .
