Язык визуального программиования ДРАКОН (Drakon) — средство общения для разработчика MQL и заказчика
2 192
7
Введение
Язык ДРАКОН разработан совместными усилиями Федерального космического агентства (Научно-производственный центр автоматики и приборостроения имени академика Н.А. Пилюгина, г. Москва) и Российской академии наук (Институт прикладной математики имени академика М.В. Келдыша, г. Москва) как обобщение опыта работ по созданию космического корабля «Буран».
В.Д. Паронджанов
Когда-то давным-давно, в стране СССР наступила гласность, и закрытая космическая разработка — Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность/Надёжность (ДРАКОН) — стала доступна широким массам. Сегодня основным популяризатором этого языка является В.Д. Паронджанов. Он организовал целый сайт, посвященный этому языку, поддерживает темы на форумах, участвует в конференциях, пишет книги... С его лёгкой руки с помощью языка ДРАКОН описывают свои процессы химики и медики.
Другие энтузиасты стали выпускать трансляторы с этого языка на более широко используемые языки программирования: C, C++, TCL/TK, Java, JavaScript... На самом деле список гораздо длиннее. И при необходимости его можно расширять, так как все известные мне редакторы формируют на выходе легко читаемые файлы (обычный текст - *.csv, *.xml; базы данных - SQLight...), и многие из этих программ имеют открытый код для правил трансляции на другие алгоритмические языки.
Дело в том, что этот язык — не "символьный", как большинство современных языков типа MQL, а графический. То есть любые алгоритмы в нём буквально рисуются на экране с помощью специальных значков-икон. И значки эти по интуитивно понятным правилам объединяются в алгоритмы. И в итоге получаются настолько простые и понятные схемы, что в них способен разобраться даже не программист. А потом эти схемы можно одним кликом перевести в работающие программы...
Вспомним понятие алгоритма.
Алгоритм — это четкое и понятное исполнителю описание, проводящее исполнителя через определенные процессы, в результате которых решается некоторая конкретная задача.
Есть и другие определения, возможно, более качественные, но я остановлюсь на этом. Просто оно мне нравится.
Итак, согласно этому определению, алгоритм — это способ решения какой-то задачи силами исполнителя. В идеале, если я составляю алгоритм, то лучше, чтобы исполнителем мог быть не только я, но и кто-то другой (или что-то другое, например, робот).
И вот сочинил я алгоритм исключительно прибыльного советника, торгующего по сложносочинённому синусоидальному мартингейлу, причем сигнал меняется в зависимости от длины свечи, отстоящей от текущей на экспоненциальную долю от дня недели, и фазы предыдущей формации из 10 пиков. Ну, Вы поняли, да? Нет??? Ну, вот же, я же всё объяснил!!!
Что Вы мне предложите, если Вам интересен этот заказ, скажем, по финансовым соображениям? Скорее всего - сесть и порисовать, правильно? Чтобы и Вам стало понятно, чего исполнять, в смысле - как кодировать. И в процессе рисования родится некая схема, будет подписана, как ТЗ, и только потом вы возьметесь это всё дело переводить в буковки кода...
Вот такой схемой и может быть рисунок в формате ДРАКОНа.
Если вы программист, и сами нарисовали эту схему, то для получения из схемы работоспособного кода часто бывает достаточно нажать пару клавиш (или, если утрировать, кликнуть мышкой большой пункт меню "Сделать хорошо"). Ну, или, как минимум, создать надёжный каркас, который потом подправить с помощью серии автозамен.
Если вы заказчик, то вам будет гораздо легче объяснить программисту, чего Вы хотите, если вы ему покажете наглядный рисунок-схему, где четко расписано, что делать в тех или иных случаях.
Например, при пересечении двух MA нужно только запомнить сигнал, а торговать в момент, когда цена отскочит от "младшей" средней, но не позже 19 часов по местному времени.
Описывать это словами... Можно. И вас поймут, в конце концов.
Но можно нарисовать схему, в которой позадавать компьютеру (точнее - абстрактному исполнителю) простые вопросы типа: "Текущее время больше 19? - или - Средние пересеклись?", - и расписать, что делать, если ответ "да" - и если ответ "нет".
Технической работы у программиста не убавится, но мысли ваши он поймёт гораздо лучше, и меньше вероятность, что наделает ошибок в первых версиях. А ведь потом эти ошибки придется исправлять, что может потребовать дополнительного времени (и/или денег).
В общем, преимущества ДРАКОН-схем есть как для программиста, так и для заказчика, который с программированием незнаком, но зато очень хорошо (лучше всех) представляет, как именно он хочет, чтобы работал его советник.
Резюмировать это вступление хочу так: для меня ДРАКОН хорош тем, что:
- Язык построен так, что он реально помогает думать. Когда я вижу перед собой нарисованный алгоритм, мне гораздо проще осознавать взаимосвязи частей в модулях и целых модулей - между собой, находить ошибки и использовать не очевидные сами по себе, но вытекающие из схемы решения.
- ДРАКОН помогает лучше понимать заказчика.
- Проще доносить до заказчика мои предложения, если таковые возникнут.
- Заказчику легче критиковать мои ошибки.
- Если заказчик нарисовал ДРАКОН-схему, то эту схему можно буквально переносить в код и считать ТЗ выполненным. Это гораздо легче, чем понимать в процессе работы, что не знаю, скажем, что делать, если сигнал не сработал. Просто для заказчика это настолько очевидно, что он забыл это уточнить, а после уточнения оказывается, что надо писать еще три экрана кода... Лучше разобраться с такими вещами до начала кодирования, и визуальные схемы в этих "разборках" сильно помогают.
Для меня графика в алгоритмах - просто чудесное средство для коммуникации. Когда двое заинтересованы в результате и ведут диалог, лучше им говорить на одном языке. И язык схем ДРАКОНа универсален для специалистов в любой профессии, если его один раз понять.
Основные среды разработки на языке ДРАКОН
При подготовке данной статьи я использовал три основных инструмента.
- Во-первых, это Drakonhub — онлайн редактор, который позволяет рисовать все виды диаграмм, используемых в языке ДРАКОН, имеет очень удобный для меня интерфейс но, к моему сожалению, не умеет экспортировать диаграммы в код. У него есть проект для программистов - drakon.tech, но он умеет только JavaScript (ну, или я не умею его готовить)... И количество доступных для не-програмистов диаграмм у drakon.tech, кажется, сильно меньше, чем у Drakonhub. В общем, для заказчиков - идеально, для разработчиков - вполне нормально, если не лень, скажем, прописывать типизацию для переменных вручную после генерации... Есть русский, английский и норвежский интерфейс.
- Во-вторых, это "Фабула" (также доступна прямая ссылка на скачивание). Программа имеет интерфейс на русском и английском языках, оффлайн приложение под Windows (хоть и написана c использованием библиотеки QT, но имеет закрытый код). Бесплатна. Интерфейс для меня - практически идеален, данные сохраняются в XML, запакованный архиватором zip (то есть при желании можно написать какой-нибудь XSLT и транслировать ваши программы напрямую), умеет трассировать алгоритмы, что может быть использовано для презентаций или создания псевдокода. Псевдокод, в свою очередь, можно с помощью серии автозамен превратить во вполне рабочую программу... Основная часть диаграмм в этой статье будет создана именно с её помощью.
- В-третьих, это DRAKON Editor, в котором интерфейс чуть менее удобен, поскольку иконы надо размещать вручную, Кроме того, некоторых икон в нём нет, а некоторые, например, выноски, реализованы не самым лучшим образом. Но зато я могу конвертировать его схемы в мой код на MQL5 без долгой подготовительной работы. И он умеет подсвечивать некоторые ключевые слова. А еще - он написан на языке TCL/TK и, соответственно, является кроссплатформенным, а, следовательно, запускается в Linux естественным образом, без Wine. Не то, чтобы это было критично, но это - небольшой дополнительный бонус. А основной плюс этого редактора - поддержка массы языков программирования. То есть схема ДРАКОНа легким движением руки может быть конвертирована в C++, Java, JavaScript, D, TCL, Go и еще кучу всего. Так что для программистов вещь весьма полезная, если Вам ДРАКОН понравится. Правда, код, который он генерирует, не всегда красив. И способы подготовки файлов... неочевидны, надо читать документацию. Но когда разберешься - работает вполне хорошо. Интерфейс - на русском и английском языках.
- Существует еще ИС Дракон, но для меня в ней есть минус в том, что она платная. Я не стал глубоко вникать в её интерфейс, поскольку мне он показался сходным с DRAKON Editor, но особых преимуществ за то время, что я её разглядывал, я не нашел.
Основная масса рисунков в этой статье, как я уже сказал, будет подготовлена с помощью "Фабулы". Её диаграммы мне кажутся наиболее красивыми без предварительной сложной подготовки.
Если по диаграмме генерируется код, я её буду делать в DRAKON Editor.
Основные команды языка
Язык ДРАКОН разрабатывался на основе существовавших в то время и хорошо известных программистам блок-схем (flowcharts). Поэтому основные элементы языка в целом соответствуют ГОСТам про блок-схемы. Но основная мощь данной разработки — в правилах размещения этих элементов на плоскости.
Первым функциональным элементом языка являются "иконы". Икона — это специальный графический символ, который определяет какое-нибудь действие, условие, операцию алгоритма.
| Изображение | Название (в скобках указаны альтернативы) | Описание | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
 | Начало (старт) | Иконка "Начало" обозначает точку старта программы. Здесь начинается выполнение алгоритма. | |||||||||||||||
 | Конец (стоп) | Иконка "Конец" обозначает завершение выполнения программы. Здесь заканчивается выполнение алгоритма. | |||||||||||||||
 | Действие (процесс) | Иконка "Действие" представляет собой обычный блок действий. В нем содержатся команды, выполняемые по порядку. | |||||||||||||||
 | Вопрос (условие, решение) | Иконка "Вопрос" используется для проверки условия. Если условие выполняется, программа идет по одной ветке, иначе по другой. | |||||||||||||||
 | Выбор (разбор) | Иконка "Выбор" является как бы распределительным узлом для нескольких вариантов. Иными словами, программа выполняет разные действия в зависимости от условий, определенных внутри "Выбора". В отличие от "Вопроса" вариантов может быть больше, чем два. | |||||||||||||||
 | Вариант | Иконка "Вариант" представляет собой условие или ветку выполнения, связанную с иконкой "Выбор" в языке ДРАКОН. Определяет, какие действия должны быть выполнены, если определенное условие в блоке "Выбор" является истинным. | |||||||||||||||
 | Имя ветки | Иконка "Имя ветки" описывает имя некоторого фрагмента в данном модуле, некий этап алгоритма, состояние программы. | |||||||||||||||
 | Адрес | Иконка "Адрес" указывает, куда надо перейти после выполнения данной ветки. | |||||||||||||||
 | Вставка | Иконка "Вставка" используется для вставки другой схемы или блока действий в текущий алгоритм. Это позволяет организовывать и структурировать код более компактно и логично. | |||||||||||||||
 | Полка | Иконка "Полка" может иметь несколько значений.
| |||||||||||||||
 | Параметры | В иконке "Параметры" помещают входные данные для алгоритма. | |||||||||||||||
 | Начало цикла ДЛЯ | Иконка "Начало цикла ДЛЯ" обычно используется совместно со следующей. Описывает повторение какого-то действия известное (вычислимое) количество раз. Например, если нам надо посчитать от 1 до 10, или перебрать все элементы в каком-то массиве... | |||||||||||||||
 | Конец цикла ДЛЯ | Иконка "Конец цикла ДЛЯ" обычно используется совместно с предыдущей. Описывает повторение какого-то действия известное (вычислимое) количество раз. | |||||||||||||||
 | Вывод | Иконка "Вывод" обозначает точку, где данные или результаты программы передаются пользователю, другой части программы или внешним устройствам. Верхняя часть содержит ключевое слово или ключевую фразу. Обычно там есть глагол. Нижняя часть содержит объект или описательную информацию. | |||||||||||||||
 | Ввод | Иконка "Ввод" указывает место, где программа ожидает получения данных от пользователя, другой программы или внешних источников. Точно так же, как вывод, содержит верхнюю и нижнюю части. | |||||||||||||||
 | Пауза | Иконка "Пауза" обозначает момент приостановки выполнения программы до определенного события или времени. | |||||||||||||||
 | Таймер | Иконка "Таймер" используется для контроля временных интервалов и планирования действий. Часто используется с иконкой "время". | |||||||||||||||
 | Время | Иконка "Время" визуализирует операции, связанные с временем и его учетом. Позволяет программе отслеживать временные интервалы и события. | |||||||||||||||
 | Параллельный процесс | Иконка "Параллельный процесс" управляет выполнением задачи, которая выполняется одновременно с основной программой. Параллельный процесс работает в фоновом режиме и его алгоритм определяется в другой ДРАКОН-схеме. Основной процесс продолжает работу, не ожидая завершения параллельной задачи. Связь с параллельным процессом может устанавливаться с помощью икон "Ввод" и "Вывод". | |||||||||||||||
 | Комментарий в основной линии | Иконка "Комментарий в основной линии" помогает сделать диаграмму более понятной. На ход программы не влияет, но даёт возможность прояснить непонятный фрагмент. | |||||||||||||||
  | Правый и левый комментарии. | Иконки правого и левого комментариев позволяют прокомментировать любое действие конкретно в том месте, где оно происходит. Как правило, поясняются переменные и параметры. | |||||||||||||||
 | Выноска | Иконки "Выноска" чаще всего используются вместо правого и левого комментариев, если надо пояснить какой-то фрагмент алгоритма. В алгоритмах, транслирующихся в программы, используется редко. Чаще это способ акцентировать внимание в алгоритмах, написанных на человеческих языках (например, для медиков), или если заказчик хочет прояснить своё описание с помощью каких-то акцентированных точек. | |||||||||||||||
 | Параллельные процессы | Иконка "Параллельный процесс" используется для запуска нескольких задач или процессов, которые выполняются одновременно. Каждая из стрелок в этой иконе может представлять отдельный поток или задачу. | |||||||||||||||
 | Петля цикла | Стрелки отображают повторяющиеся события, точное число повторения для которых неизвестно. Например, проверять, закипел ли чайник, до тех пор, пока не закипит. | |||||||||||||||
 | Петля силуэта | Используется только в одном месте диаграммы: для указания продолжения действия и перехода к следующей ветке силуэта (см. далее). |
Иногда используют и другие иконы, такие, как "простой ввод" (выглядит, как верхняя часть иконки "Вывод") или прямоугольник со скругленными углами. Некоторые программы не позволяют использовать все иконы. Но в целом в таблице дан практически исчерпывающий набор фрагментов, из которых строятся диаграммы.
Создание простых визуальных схем ("примитивов")
Схемы языка ДРАКОН строятся по определенным законам.
Как уже было сказано, основным строительным блоком схемы являются иконы. Однако для того, чтобы они правильно взаимодействовали, им нужны линии связи.
Линии связи бывают горизонтальными и вертикальными, НО
Действия происходят только по вертикали.
Горизонтальные связи указываются только при выборе одного из нескольких вариантов или при каких-то других вспомогательных действиях. Если вспомогательных действий типа ввода параметров в функцию или комментариев для данного алгоритма нет, то весь алгоритм будет размещен на едином вертикальном "шампуре".
Например, нам необходимо получить сумму двух чисел. Оба числа мы получаем от пользователя, выводим данные, скажем, в консоль с помощью функции printf или Print, в данном случае неважно. Как могла бы выглядеть схема на языке ДРАКОН? Да очень просто:
Рисунок 1. Алгоритм суммы двух чисел
А если захотим именно запрограммировать этот код, то, скорее всего, нам понадобится функция, и она должна будет принимать параметры (вспомогательное действие). Тогда мы нарисуем это таким образом:
Рисунок 2. Суммирование в виде функции.
И сразу код, сгенерированный программой по моей схеме:
double Summ(double a, double b) { // item 6 return (a+b); }
Итак, запомнили первое правило: основное направление ДРАКОН-схем - сверху вниз. То есть, если алгоритм выполняется линейно, его примитив всегда будет нарисован вертикально, и выполнять его надо сверху вниз. Поэтому стрелки диаграмме не нужны - и так всё ясно.
Но если нам нужно ветвление? Если какие-то действия происходят только при каких-то условиях? Скажем, вход в сделку - только по пересечению скользящих средних будет решаться с помощью иконки вопроса:
Рисунок 3. Алгоритм входа в сделку по пересечению скользящих средних
Каждая икона условия всегда имеет два выхода: один - снизу, и один - справа (и только так). То есть любые действия в алгоритме всегда будут происходить сверху вниз и слева направо. Стрелки снова не нужны. При проверке алгоритма мы просто идём по линиям, пока не дойдём до конца. А потом, как правило, останавливаемся...
Иногда бывает, что решение надо принимать на основе не двух, а трех или более вариантов. Скажем, пользователь нажал на определённую клавишу, и в зависимости от того, на какую именно клавишу он нажал, программа должна выполнить определённые действия. Нарисовать это можно, конечно, и с помощью обычных вопросов, но схема получится громоздкой.
Гораздо лучше подойдет в этом случае конструкция выбора.
Рисунок 4. Обработка нажатий клавиш.
Обратите внимание, что последняя икона варианта осталась пустой. В языке MQL этот вариант соответствует оператору default - то есть выполняется действие по умолчанию, если никакой другой вариант не подошёл.
На этом примере можно проследить еще одно правило ДРАКОНа: все вертикальные ветви располагаются слева направо, причем чем правее, вариант, тем он хуже. Самый левый вариант иногда называют "Царский путь" или "Счастливый путь" (happy path).
Если варианты равнозначны, их просто упорядочивают по какому-то критерию. Например, я упорядочил по расположению нажатой буквы в алфавите.
Но, правда, существует ситуация, когда необходимо перейти к началу какого-то блока, не доходя до конца программы. Это - циклы ПОКА.
Рисунок 5. Ждём сигнал, пока он не появится. Действие "Ждём сигнал" выполняется хотя бы один раз при любых обстоятельствах.
Или тот же цикл можно переписать так, чтобы он сначала проверял условие, а уж затем выполнял какие-то действия.
Рисунок 6. Ждём сигнал, пока он не появится. Действие "Ждём сигнал" может ни разу не выполниться, если сигнал уже пришёл.
В любом случае стрелка здесь уже является необходимым элементом, без неё схема будет читаться гораздо хуже.
И еще есть одно важное правило про циклы. У цикла может быть сколько угодно выходов, но вход может быть только один. То есть нельзя протянуть стрелку из произвольного места программы в произвольное место в цикле. Нужно всегда возвращаться к началу.
Схемы "Силуэт" на ДРАКОНе
Поскольку ДРАКОН — язык визуальный, важно, чтобы его схемы легко читались. А для этого лучше, чтобы вся схема входила на экран (или лист) целиком.
Это требование далеко не всегда осуществимо, но к этому надо стремиться. И помочь в этом может еще один способ размещения икон языка: "Силуэт".
Силуэт — это просто способ разбить какую-то длинную функцию на составные части, на этапы выполнения, но при этом оставить её единым целым.
Вот, например, как могла бы выглядеть обработка тика в типовом советнике, записанная в виде силуэта.
Рисунок 7. Силуэт - вторая основная конфигурация схемы в языке ДРАКОН
Сверху каждой ветви находится её условное название на человеческом языке. Снизу - адрес перехода - куда перенаправить поток команд после того, как данная ветвь выполнена. Как правило, переход совершается на соседнюю ветку, но бывают случаи, когда нужно перейти куда-то в другое место.
Если переход - дальше вправо, то просто указывается название ветви.
Если переход происходит к началу этой же ветви или к ветви левее, маркеры начала и конца соответствующих ветвей помечаются черным треугольником:
Рисунок 8. Цикл в одной ветви силуэта
Если Вам приходится использовать такой цикл, обязательно убедитесь, что у вас есть условие выхода из него, которое переведёт программу в другую ветку. Иначе цикл грозит стать бесконечным.
Я стараюсь избегать таких циклов в своих схемах. В тех задачах, что я решаю, без них можно обойтись в 95.4% случаев...
Фактически силуэт является диаграммой состояния. Как правило, редакторы каждую ветвь именно так и понимают - как некие состояния процесса в данный момент, так силуэт и интерпретируют - как бесконечный цикл с выбором состояний с помощью оператора switch-case внутри. Поэтому и нужны метки на входе и выходе: программе нужно знать, куда переключаться, а человеку - видеть, какой именно фрагмент активен в тот или иной момент времени.
Вход в ветку возможен только через ее начало. Выход из последней ветки осуществляется через икону «конец».
Дополнительные нюансы ДРАКОН-схем
Надеюсь, вы обратили внимание, что ни на одной приведённой выше схеме линии не пересекаются, если нет соединения. Это принципиальный момент, добавляющий схемам наглядности. Пересечений быть не должно. Могут быть только слияния путей или переход по меткам. Там, где есть пересечение, можно выбрать этот путь при движении задачи к решению.
Кстати, на рисунке 7 ветка добавления дополнительных позиций (третья слева) нарисована не совсем правильно. Параллельных линий на рисунке должно быть как можно меньше. Это правило тоже добавляет наглядности. К моему сожалению, "Фабула" правильно рисовать ветвления не умеет. Хотя это и не ошибка, скорее - погрешность интерпретации.
Исключение из правила "Движение либо вниз, либо вправо" - самая нижняя линия диаграммы, связывающая шампуры силуэта в единое целое. Она всегда возвращает процесс к началу, чтобы выбрать новое состояние. Поэтому по ней мы движемся справа налево, к стрелке.
В принципе, на одном листе почти все программы позволяют создать несколько схем. И иногда это может быть оправдано.
Если схемы небольшие, и почти все являются вертикалями (а силуэты можно сделать очень компактными)... И между схемами есть достаточное расстояние (или они хорошо маркированы цветом, а еще лучше - дополнительными границами)... При исполнении всех этих условий наглядность диаграмм при совмещении может повыситься.
Если ваши схемы предназначены для печати на бумаге, имеет смысл попробовать расположить их максимально компактно, используя рекомендации предыдущего абзаца
Однако во всех остальных случаях лучше всё же располагать каждую схему на отдельном пространстве. Особенно, если среди них есть большие "силуэты" или эти схемы предназначены для печати на бумаге в черно-белом оформлении. Чаще всего ДРАКОН всё-таки про наглядность, а не про компактность. Именно наглядность сокращает умственные усилия на понимание: "Чего же тут нарисовано???", - и позволяет эти усилия направить на разработку эффективных решений.
Импорт схем из ДРАКОН в MQL
Когда я составляю хороший и большой алгоритм с помощью графических икон, хочется минимизировать усилия по переносу нарисованного в написанное.
Как правило, для этих целей я использую DRAKON Editor.
Открыв редактор, первым делом надо создать (или открыть существующий) файл.
Рисунок 9. DRAKON Editor - Диалог создания файла
Дело в том, что DRAKON Editor (DE) использует автосохранение: все изменения на экране сразу сохраняются в файле.
Желтыми буквами в этом окне написано, что когда вы будете таскать иконы по экрану при создании диаграмм, можно использовать клавишу "Shift" - тогда перетаскивание станет "умным".
Нарисованные схемы будем транслировать в язык Java. Это - самый простой вариант, если вам не хочется писать специальный парсер для MQL (мне всё еще не хочется). Структура Java файлов максимально близка к структуре MQL5 программ, поэтому сгенерированные файлы будут компилироваться с минимальными переделками.
В левом верхнем углу основного окна программы находится кнопка открытия описания файла и меню "File", где тоже можно найти этот пункт:
Рисунок 10. DRAKON Editor - Меню и кнопка свойств файла
Описание файла функционально!!!
В описании кроме пояснений общего плана можно вставить две секции, которые будут полностью переданы в готовую программу. Пока там еще ничего нет, эти секции будут выглядеть очень просто:
===header=== ===class=== class Main {
После строки "===class===" достаточно записать слова "class Main {". Обратите внимание, что здесь одна фигурная скобка. Вторую редактор поставит сам во время генерации.
Класс в файле может быть только один.
Всё, что вставлено после строки "===header===", DE вставит в ваш файл напрямую. Поэтому, если вы пишете программу полностью на языке ДРАКОН, в эту секцию необходимо поместить все глобальные переменные, инструкции "#include", описания структур и перечислений и т.д.
Всё, что находится перед секцией "===header===", игнорируется. То есть здесь действительно можно вставлять любые текстовые описания
Если вы пишете простой индикатор, слова "class Main {" и завершающую фигурную скобку из финального файла нужно будет удалить.
Если же вы понимаете, как работает ООП, то можно использовать описание класса прямо в этом же заголовке, как обычно, исключая реализацию функций. Реализация функций будет происходить в диаграммах. Просто имейте в виду, что в Java всё есть класс, а в MQL всё же есть функции, работающие в глобальной области видимости.
Я хочу продемонстрировать создание простого индикатора NR4, который маркирует свечу, если её размер меньше, чем размер других свечей перед ней. Количество "больших" свечей задаётся во входных параметрах. Часто появление такой свечи обозначает вероятность скорого резкого движения.
===header=== //+------------------------------------------------------------------+ //| NR4.mq5 | //| Oleg Fedorov (aka certain) | //| mailto:coder.fedorov@gmail.com | //+------------------------------------------------------------------+ #property copyright "Oleg Fedorov (aka certain)" #property link "mailto:coder.fedorov@gmail.com" #property version "1.00" #property indicator_chart_window #property indicator_buffers 2 #property indicator_plots 2 //--- plot NRBars #property indicator_label1 "NRBarsUp" #property indicator_type1 DRAW_ARROW #property indicator_color1 clrRed #property indicator_style1 STYLE_SOLID #property indicator_width1 0 //--- plot NRBars #property indicator_label2 "NRBarsDn" #property indicator_type2 DRAW_ARROW #property indicator_color2 clrRed #property indicator_style2 STYLE_SOLID #property indicator_width2 0 //--- input variables input int NRPeriod=4; //--- indicator buffers double NRBarsBufferUp[]; double NRBarsBufferDn[]; ===class=== class Main {
ФУХ! Описание файла закрываем...
Теперь из настроек осталось только одно: сказать редактору, что наш файл надо транслировать в Java.
Выбираем меню "File -> File properties" и в появившемся диалоге выбираем из списка в верхней строке "Java".
Рисунок 11. Выбор языка, в который транслируется схема.
Всё, настройка закончена. Теперь можно приступить к программированию алгоритма.
В иконах можно писать любой текст, но в данном случае каждая икона будет содержать фрагмент кода, идущий в конечный файл. Если это будет демонстрация для заказчика, достаточно просто написать комментарии на человеческом языке, если же вы хотите хранить в диаграммах компилируемый код, пишите, что должно происходить, достаточно подробно... У меня - второй случай.
И, да, иконка "Вставка" в DE при компиляции не работает, надо использовать просто икону "Действие".
Для каждой функции должна быть создана своя диаграмма.
DE это прямо требует (другие редакторы более "лояльны"). Здесь нельзя создать несколько схем, не создав несколько сущностей для диаграмм с помощью кнопки на панели или сочетания клавиш Ctrl+N.
В моём случае получилось всего две функции: OnInit и OnCalculate. Вот они:
Рисунок 12. Функция OnInit
Рисунок 13. Функция OnCalculate
Если текст на рисунках слишком мелкий, скачайте и установите DRAKON Editor (на сайте есть подробная инструкция и описаны все зависимости). А затем откройте файл со схемами, который я приложу, как вложение, напрямую.
Ну, а дальше - с помощью меню "DRAKON -> Generate code" пробуем транслировать схему в компилируемый код. Если в схеме есть ошибки (например, не дотянули линию до другой линии или иконки), DE об этом предупредит в панели снизу. Если ошибок нет, в папке, которая содержит файл проекта, появится файл с расширением *.java.
Сохраните его в Ваш каталог индикаторов, измените расширение на *.mq5, уберите описание класса, если необходимо, скомпилируйте и запустите...
Вот содержимое моего файла до удаления всего лишнего:
// Autogenerated with DRAKON Editor 1.31 //+------------------------------------------------------------------+ //| NR4.mq5 | //| Oleg Fedorov (aka certain) | //| mailto:coder.fedorov@gmail.com | //+------------------------------------------------------------------+ #property copyright "Oleg Fedorov (aka certain)" #property link "mailto:coder.fedorov@gmail.com" #property version "1.00" #property indicator_chart_window #property indicator_buffers 2 #property indicator_plots 2 //--- plot NRBars #property indicator_label1 "NRBarsUp" #property indicator_type1 DRAW_ARROW #property indicator_color1 clrRed #property indicator_style1 STYLE_SOLID #property indicator_width1 0 //--- plot NRBars #property indicator_label2 "NRBarsDn" #property indicator_type2 DRAW_ARROW #property indicator_color2 clrRed #property indicator_style2 STYLE_SOLID #property indicator_width2 0 //--- input variables input int NRPeriod=4; //--- indicator buffers double NRBarsBufferUp[]; double NRBarsBufferDn[]; class Main { int OnCalculate(const int rates_total, const int prev_calculated, const datetime &time[], const double &open[], const double &high[], const double &low[], const double &close[], const long &tick_volume[], const long &volume[], const int &spread[]) { // item 15 int i,j, limit; // item 16 if (rates_total < NRPeriod) { // item 19 return 0; } else { // item 20 if (prev_calculated < NRPeriod) { // item 23 limit = NRPeriod; // item 24 ArrayInitialize(NRBarsBufferUp, EMPTY_VALUE); ArrayInitialize(NRBarsBufferDn, EMPTY_VALUE); } else { // item 25 limit = rates_total - NRPeriod; } // item 310001 i = limit; while (true) { // item 310002 if (i<rates_total-1) { } else { break; } // item 340001 j=1; while (true) { // item 340002 if (j<NRPeriod) { } else { break; } // item 36 if (high[i]-low[i]>high[i-j]-low[i-j]) { // item 39 break; } else { } // item 340003 j++; } // item 40 if (j==NRPeriod) { // item 43 NRBarsBufferUp[i]=high[i]; NRBarsBufferDn[i]=low[i]; } else { } // item 310003 i++; } } // item 48 return(rates_total); } int OnInit() { // item 11 //--- indicator buffers mapping SetIndexBuffer(0,NRBarsBufferUp,INDICATOR_DATA); SetIndexBuffer(1,NRBarsBufferDn,INDICATOR_DATA); // item 12 //--- setting a code from the Wingdings charset as the property of PLOT_ARROW PlotIndexSetInteger(0,PLOT_ARROW,218); PlotIndexSetInteger(1,PLOT_ARROW,217); // item 13 //--- IndicatorSetString(INDICATOR_SHORTNAME,"NR4 ("+IntegerToString(NRPeriod)+")"); // item 14 //--- return(INIT_SUCCEEDED); } }
Еще раз напомню: чтобы данный простой индикатор заработал, выделенный желтым текст необходимо удалить — и сверху, и снизу. Здесь я сознательно не использовал стилизатор, чтобы читатель мог оценить, как именно будет отформатирован его файл автоматикой DE.
Читать этот код, конечно, гораздо сложнее, чем если бы я писал его руками, но... Он работает. А читать его не надо, надо смотреть на схемы. ;-)
Заключение
Если вы разработчик, и вам понравился ДРАКОН, смело пользуйтесь любым инструментом для создания диаграмм, которые я называл выше. Лучше всего, если вы самостоятельно протестируете каждый из перечисленных редакторов и сложите своё мнение, что лично Вам лучше, что хуже... По сути, они все несложные.
Если Вы хотите приучить заказчика к порядку, дайте ему ссылку на Dragon.Tech или на drakonhub, объясните в трёх словах, как создать проект на человеческом языке и как соотносятся между собой иконы, и скажите, что словами описывать, что он хочет видеть — это нормально. Главное, чтобы была понятная структура.
Если же Вы заказчик, и дошли до этого места, то Вам и так уже всё ясно. ;-)
За кадром осталось много всяких тем: и использование ДРАКОНа в интерактивных презентациях, и способы упорядочивать и структурировать для более простого запоминания любую информацию, не только компьютерные программы, и критика языка ДРАКОН и всех графических языков...
Будет интересно — пишите в личные сообщения, или в комментариях к данной статье — обсудим. Можно сходить на сайт В.Д. Паронджанова и походить там по ссылкам — можно будет "нарыть" еще о-очень много всякого...
А я надеюсь, что мне удалось хоть как-то заронить интерес к данному подходу и что хоть пара человек из прочитавших начнут применять этот замечательный инструмент в своей практике.
Если кому-то потребуются исходники других алгоритмов, описанных в данной статье, пишите, я вам их вышлю.
Вложение. В архиве — файл проекта DRAKON Editor, содержащий алгоритм индикатора, описанного в предыдущем разделе. Из этого файла можно сгенерировать вполне рабочий код индикатора NR4.
Объектно-ориентированное программирование (ООП) в MQL5
Готовые шаблоны для подключения индикаторов в экспертах (Часть 2): Индикакторы объёма и Билла Вильямса
Разработка MQTT-клиента для MetaTrader 5: методология TDD
Популяционные алгоритмы оптимизации: Тасующий алгоритм прыгающих лягушек (Shuffled Frog-Leaping, SFL)
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Навеяло:
Я с изумлением читал вывески.
...А можете немного развернуть ассоциацию?
P.S. "Понедельник" тоже обожаю. Как и некоторые другие их вещи.
Похожая публикация.
А можете немного развернуть ассоциацию?
P.S. "Понедельник" тоже обожаю. Как и некоторые другие их вещи.
Ничего особенно. Начало такое сюрреалистичное: "Язык ДРАКОН разработан совместными усилиями Федерального космического агентства", на мгновение показалось, что Стругацких читаю.
Ничего особенно. Начало такое сюрреалистичное: "Язык ДРАКОН разработан совместными усилиями Федерального космического агентства", на мгновение показалось, что Стругацких читаю.
Жуткое зрелище! Как представлю, сколько разрабам ПО Буран пришлось нарисовать диаграмм, чтобы осуществить автоматическую посадку, слезы выступают на глазах!
Жуткое зрелище! Как представлю, сколько разрабам ПО Буран пришлось нарисовать диаграмм, чтобы осуществить автоматическую посадку, слезы выступают на глазах!