Lenguaje de programación visual Drakon: una herramienta de comunicación para desarrolladores y clientes MQL

Introducción

El lenguaje DRAKON se desarrolló gracias a los esfuerzos conjuntos de la Agencia Espacial Federal (Centro de Automatización e Instrumentación del Académico N.A. Pilyugin, en Moscú) y la Academia Rusa de las Ciencias (Instituto de Matemáticas Aplicadas del Académico M.V. Keldysh, en Moscú) como generalización de la experiencia de los trabajos de desarrollo de la nave espacial Burán.

V.D. Parondzhanov.

Hace mucho tiempo, cuando la glasnost llegó a la URSS, y un desarrollo espacial cerrado, -el Lenguaje Algorítmico Ruso Amigable que Proporciona Visibilidad/Fiabilidad (DRAKON)- se puso a disposición de las masas. En la actualidad, el principal divulgador de este lenguaje es V.D. Parondzhanov, que en su día organizó un sitio web completo dedicado al lenguaje, mantiene hilos en foros, participa en conferencias, escribe libros... Gracias al lenguaje DRAKON, químicos y médicos describen sus procesos con facilidad.

Después otros entusiastas empezaron a producir conversores de este lenguaje a los lenguajes de programación más utilizados: C, C++, TCL/TK, Java, JavaScript,... En realidad, la lista es mucho más larga, y puede ampliarse de ser necesario, porque todos los editores que conozco forman archivos fácilmente legibles (textos simples en el formato *.csv, *.xml; bases de datos como SQLight...), y muchos de estos programas tienen código abierto para reglas de conversión a otros lenguajes algorítmicos.

La cuestión es que, a diferencia de la mayoría de los lenguajes modernos como MQL, este lenguaje no es un lenguaje "simbólico", sino gráfico. Es decir, los algoritmos que contiene se dibujan literalmente en la pantalla con iconos especiales, y estos iconos se combinan en algoritmos según reglas intuitivas. Como resultado, los esquemas resultan tan sencillos y claros que incluso los no programadores pueden entenderlos, así que estos esquemas pueden convertirse en programas operativos con un solo clic....

Recordemos el concepto de algoritmo.

Un algoritmo es una descripción clara y comprensible para el ejecutor, que le guía a través de ciertos procesos que dan como resultado la resolución de algún problema específico.

Existen otras definiciones, quizá mejores, pero nos detendremos aquí. Simplemente esta definición me gusta.

Así pues, según dicha definición, un algoritmo es una forma de resolver algún problema por parte de un cierto ejecutor. De manera ideal, si estamos montando un algoritmo, resultará mejor que el ejecutor sea otra persona (u otra cosa, como un robot), además de nosotros mismos.

Y así hemos compuesto el algoritmo de un asesor extremadamente rentable, que comercia según un martingale sinusoidal complejo: la señal variará dependiendo de la longitud de una vela cuya distancia respecto a la actual será una fracción exponencial de un día de la semana, y con una fase de formación anterior de 10 picos. Bueno, ya nos hacemos una idea, ¿no? ¿No? Bueno, pues ya está, ¡lo he explicado todo!

¿Qué me propondría usted si le interesa este encargo, digamos, por motivos económicos? Lo más probable sería sentarse y dibujar un poco, ¿no? Para que quede claro qué realizar, me refiero a cómo escribir el código. Y en el proceso de dibujado, surgirá un cierto esquema que se firmará como tarea técnica o término de referencia (TdR), y solo entonces tomaremos todos estos materiales para convertirlos en código....

Así podría ser un dibujo en formato DRAKON.

Si es usted programador y ha dibujado por sí mismo este esquema, a menudo bastará con pulsar un par de teclas (o, para exagerar, hacer clic en una gran opción del menú "Hacer bien") para obtener un código viable a partir del esquema. Bueno, o, como mínimo, crear un marco sólido que luego pueda retocar con una serie de auto-reemplazos.

Si usted es un cliente, le resultará mucho más fácil explicar al programador lo que desea si le muestra un esquema visual en el que se describa claramente qué hacer en determinados casos.

Por ejemplo, cuando se cruzan dos MA, solo tiene que recordar la señal y comerciar en el momento en que el precio rebote en la media "menor", pero no más tarde de las 19 horas, hora local.

Describir esto con palabras... Es posible. Y al final le entenderán.

Pero es posible dibujar un esquema en el que hacer al ordenador (más precisamente, al ejecutor abstracto) preguntas simples como: "¿Es la hora actual mayor que 19?", o, digamos, "¿se han cruzado las medias?", y describir qué hacer si la respuesta es "sí" o si la respuesta es "no".

El programador no tendrá menos trabajo técnico, pero entenderá mucho mejor sus ideas y será menos probable que cometa errores en las primeras versiones. Y luego habrá que corregir dichos errores, lo que puede requerir más tiempo (y/o dinero).

En general, los esquemas DRAKON tienen ventajas tanto para el programador como para los clientes que no están familiarizados con la programación, aunque tengan una idea muy buena (mejor que nadie) de cómo quieren que funcione sus asesores.

Resumiendo esta introducción, querría decir que, para mí, DRAKON es bueno porque:

• El lenguaje está construido de forma que realmente nos ayuda a pensar. Cuando veo un algoritmo dibujado delante de mí, me resulta mucho más fácil darme cuenta de las interrelaciones de las partes en los módulos y de los módulos enteros entre sí, encontrar errores y usar soluciones que no sean obvias en sí mismas, sino que se desprendan del esquema.
• DRAKON nos ayuda a comprender mejor al cliente.
• Resulta más sencillo comunicar nuestras sugerencias, si las hay, al cliente.
  
• Para el cliente resulta más fácil criticar nuestros errores.
• Si el cliente ha dibujado un esquema DRAKON, entonces este esquema podrá convertirse literalmente en código y considerar cumplidos los TdR. Esto es mucho más sencillo que darnos cuenta durante el proceso de que no sabemos, digamos, qué hacer si la señal no funciona. Es que para el cliente resulta tan obvio que se ha olvidado de aclararlo, y después de aclararlo resulta que debemos escribir tres pantallas más de código... Es mejor aclarar estas cosas antes de empezar a programar, y los esquemas visuales nos sirven de gran ayuda en esta tarea.
  

En mi opinión, los gráficos en los algoritmos son una herramienta maravillosa de comunicación. Cuando dos personas están interesadas en el resultado y dialogan, es mejor que hablen el mismo idioma, y el lenguaje de los esquemas DRAKON es universal para los expertos de cualquier profesión, si lo entienden una primera vez.

Principales entornos de desarrollo en el lenguaje DRAKON

Para preparar este artículo, hemos utilizado tres herramientas principales.

• En primer lugar, Drakonhub, un editor en línea que permite dibujar todo tipo de diagramas utilizados en el lenguaje DRAKON; posee una interfaz muy fácil de usar, pero, por desgracia, desconozco cómo exportar diagramas a código. Tiene un proyecto para programadores: drakon.tech, pero solo sabe trabajar con JavaScript (bueno, o no sé cómo prepararlo)... Asimismo, el número de diagramas disponibles para no programadores en drakon.tech parece ser mucho menor que en drakonhub. En general, para los clientes resulta ideal, mientras que para los desarrolladores es bastante normal, si no somos perezosos, por ejemplo, para especificar la tipificación de las variables manualmente después de la generación... Hay interfaces en ruso, inglés y noruego.
  
• En segundo lugar, me refiero a "fabula" (igualmente disponible para la descarga en este enlace directo). El programa dispone de una interfaz en ruso e inglés y una aplicación offline para Windows (aunque se ha escrito usando la biblioteca QT, tiene un código cerrado). Es gratis. La interfaz para mí es casi perfecta, los datos se guardan en XML, empaquetado con archivador zip (es decir, si quiere puede escribir algo de XSLT y convertir sus programas directamente), puede rastrear algoritmos que pueden utilizarse para presentaciones o para crear pseudo-códigos. El pseudocódigo, a su vez, puede convertirse en un programa totalmente operativo usando una serie de auto-reemplazos... La mayoría de los diagramas de este artículo se crearán con él.
• En tercer lugar, tenemos el DRAKON Editor, en el que la interfaz es un poco menos cómoda, porque debemos colocar los iconos manualmente, además, algunos iconos no están presentes, y otros, por ejemplo, las notas finales, no están implementados de la mejor manera. Pero podemos convertir sus esquemas en nuestro propio código MQL5 sin mucho trabajo preparatorio, y sabe destacar algunas palabras clave. Asimismo, está escrito en lenguaje TCL/TK y por lo tanto es multiplataforma, así que se ejecutará en Linux naturalmente, sin Wine. No es que resulte fundamental, pero es un pequeño extra. El principal punto a favor de este editor es que ofrece soporte a multitud de lenguajes de programación. Es decir, el esquema DRAKON puede convertirse a C++, Java, JavaScript, D, TCL, Go y un montón de cosas más con apenas algunas manipulaciones. Así que para los programadores resulta algo muy útil, si le gusta DRAKON. Bien es cierto que el código que genera no siempre es bonito, y las formas de preparar los archivos... no son obvias, deberemos leer la documentación. Pero una vez nos aclaremos, funcionará bastante bien. La interfaz está en ruso e inglés.
  
• También tenemos IS Drakon, pero el inconveniente para mí es que hay que pagarlo. No hemos profundizado en su interfaz, parece bastante similar a DRAKON Editor, aunque tampoco hemos encontrado ninguna ventaja especial durante su análisis.

La mayor parte de las figuras de este artículo, como ya hemos dicho, se prepararán utilizando "Fabula". Sus diagramas me parecen los más bonitos sin necesidad de realizar complicadas preparaciones previas.

Si generamos un código a partir del diagrama, lo haremos en DRAKON Editor.

Comandos básicos del lenguaje

El lenguaje DRAKON se desarrolló a partir de esquemas de flujo que existían en aquella época y eran bien conocidos por los programadores. Por lo tanto, los elementos básicos del lenguaje se corresponderán en general con los cánones sobre esquemas de bloques. No obstante, la principal fuerza de este diseño reside en las reglas de colocación de estos elementos en el plano.

El primer elemento funcional del lenguaje serán los "iconos". Un icono es un símbolo gráfico especial que define alguna acción, condición u operación de un algoritmo.

Imagen	Nombre (alternativas entre paréntesis)	Descripción
	Inicio	El icono "Inicio" indica el punto de inicio del programa. Aquí se inicia la ejecución del algoritmo.
	Fin (parada)	El icono "Fin" indica el final de la ejecución del programa. Aquí termina la ejecución del algoritmo.
	Acción (proceso)	El icono "Acción" es un bloque de acción normal. Contiene comandos que se ejecutarán en orden.
	Pregunta (condición, solución)	El icono "Pregunta" sirve para comprobar una condición. Si esta se cumple, el programa seguirá una rama, de lo contrario, seguirá otra.
	Selección (análisis sintáctico)	El icono "Selección" es como un nodo de distribución de varias opciones. En otras palabras, el programa realizará diferentes acciones en función de las condiciones definidas dentro de la "Selección". A diferencia de la "Pregunta", puede haber más de dos opciones.
	Opción	El icono "Opción" representa la condición o rama de ejecución asociada al icono "Selección" en el lenguaje DRAKON. Determina qué acciones deberán realizarse si la condición definida en el bloque "Selección" es verdadera.
	Nombre de la rama	El icono "Nombre de rama" describe el nombre de algún fragmento de este módulo, alguna etapa del algoritmo o un estado del programa.
	Dirección	El icono "Dirección" indica dónde ir después de ejecutar esta rama.
	Inserción	El icono "Inserción" sirve para insertar otro esquema o bloque de acción en el algoritmo actual. Esto nos permite organizar y estructurar el código de forma más compacta y lógica.
	Estante	El icono de la estante puede tener varios significados. Valor Parte superior Parte inferior Orden al ejecutor Ejecutor. Por ejemplo, un contable. Orden. Por ejemplo, Imprime la factura Enviar un mensaje del remitente al destinatario Emisor y receptor. Por ejemplo, un navegador y un servidor de aplicaciones. Un mensaje, por ejemplo, la solicitud "Iniciar sesión con Facebook". Realizar una acción sobre un objeto Frase clave con acción Objeto sobre el que se realizará la acción. Asignar un valor a una variable Variable Valor A veces también se usa el "triple estante". Autor
	Parámetros	En el icono "Parámetros" se colocan los datos de entrada para el algoritmo. Por ejemplo, para construir una ruta, debemos conocer el punto de partida y el punto de destino. Algunos programas permiten separar los parámetros de entrada de los de salida. Los parámetros de entrada se encontrarán a la izquierda, y los de salida, a la derecha.
	Inicio del ciclo PARA	El icono "Inicio de un ciclo PARA" se utiliza normalmente junto con el icono siguiente. Describe la repetición de una acción un número conocido (computable) de veces. Por ejemplo, si necesitamos contar del 1 al 10, o iteraremos todos los elementos de un array.....
	Fin de ciclo PARA	El icono "Fin del ciclo PARA" suele utilizarse junto con el icono anterior. Describe la repetición de una acción un número conocido (computable) de veces.
	Salida	El icono "Salida" indica el punto en el que los datos o resultados del programa son transmitidos al usuario, a otra parte del programa o a dispositivos externos. La parte superior contiene la palabra o frase clave. Suele contener un verbo. La parte inferior contiene el objeto o cierta información descriptiva.
	Entrada	El icono "Entrada" indica el lugar en el que el programa espera recibir los datos del usuario, de otro programa o de fuentes externas. Al igual que la salida, contiene una parte superior y una inferior.
	Pausa	El icono "Pausa" indica cuándo se detiene la ejecución del programa hasta un determinado evento o momento.
	Temporizador	El icono "Temporizador" permite controlar intervalos temporales y planificar acciones. Se usa a menudo con el icono "tiempo".
	Tiempo	El icono "Tiempo" visualiza las operaciones relacionadas con el tiempo y su contabilización. Permite al software monitorear intervalos temporales y eventos.
	Proceso paralelo	El icono "Proceso paralelo" controla la ejecución de una tarea ejecutada simultáneamente con el programa principal. La parte superior del icono puede contener los comandos "Iniciar", "Detener", "Parar" o "Reiniciar". Los procesos paralelos se ejecutan en segundo plano y su algoritmo se define en otro esquema DRAKON. El proceso principal continuará ejecutándose sin esperar a que finalice la tarea paralela. La comunicación con un proceso paralelo puede establecerse usando los iconos "Entrada" y "Salida".
	Comentario en la línea principal	El icono "Comentario en la línea principal" facilita la comprensión del diagrama. No afecta al desarrollo del programa, pero ofrece la oportunidad de aclarar un fragmento no del todo claro.
	Comentarios a derecha e izquierda.	Los iconos de comentario a derecha e izquierda permiten comentar cualquier acción específicamente donde se produce. En general, se ofrecen explicaciones de las variables y parámetros.
	Llamada de atención	Los iconos "Llamada de atención" se utilizan más a menudo en lugar de los comentarios a derecha e izquierda, si necesitamos explicar algún fragmento del algoritmo. Rara vez se usa en algoritmos convertidos a programas. Con mayor frecuencia supone una forma de acentuar algo en algoritmos escritos en lenguaje humano (por ejemplo, para médicos), o si el cliente quiere aclarar su descripción con algunos puntos destacados.
	Procesos paralelos	El icono "Proceso paralelo" se usa para iniciar varias tareas o procesos que se ejecutan simultáneamente.  Cada una de las flechas de este icono puede representar un hilo o tarea distinta.
	Lazo de ciclo	Las flechas muestran sucesos recurrentes cuyo número exacto de repeticiones nos resulta desconocido. Por ejemplo, comprobar si la tetera ha hervido hasta que finalmente lo haga.
	Lazo de silueta	Solo se utiliza en un lugar del diagrama: para indicar la continuación de una acción y pasar a la siguiente rama de silueta (véase más abajo).

A veces se utilizan otros iconos, como "entrada simple" (se parece a la parte superior del icono "Salida") o un rectángulo con las esquinas redondeadas. Algunos programas no permiten usar todos los iconos. Pero, en general, la tabla ofrece un conjunto casi exhaustivo de los fragmentos a partir de los cuales se construyen los diagramas.

Creación de esquemas visuales sencillos ("primitivas")

Los esquemas lingüísticos de DRAKON se construyen según ciertas leyes.

Como ya hemos dicho, el elemento básico del sistema son los iconos. No obstante, para que interactúen adecuadamente, necesitarán líneas de conexión.

Las líneas de conexión son horizontales y verticales, PERO

Las acciones solo tienen lugar verticalmente.

Las conexiones horizontales solo se indican al seleccionar una de varias opciones o alguna otra acción auxiliar. Si para un algoritmo dado no existen acciones auxiliares como introducir parámetros en una función o comentarios, el algoritmo completo se colocará en un único "pincho" vertical.

Por ejemplo, necesitamos obtener la suma de dos números. Obtenemos ambos números del usuario, mostramos los datos a, digamos, la consola usando la función printf o Print, no importa en este caso. ¿Qué aspecto podría tener un esquemas en el lenguaje DRAKON? Pues es muy sencillo:

Figura 1. Algoritmo para la suma de dos números

Y si deseamos programar este código, lo más probable es que necesitemos una función, y tendrá que aceptar parámetros (acción auxiliar). Entonces dibujaremos esto de la forma que sigue:

Figura 2. Suma en forma de función.

E inmediatamente el código generado por el programa usando nuestro esquema:

double Summ(double a, double b) {
        // item 6
        return (a+b);
    }

Por ello, recuerde la primera regla: la dirección principal de los gráficos DRAKON es de arriba abajo. Es decir, si un algoritmo se ejecuta linealmente, su primitiva siempre se diseñará verticalmente y deberá ejecutarse de arriba a abajo. Por consiguiente, el diagrama no necesitará flechas: todo está claro tal cual.

Pero ¿y si necesitamos una ramificación? ¿Y si algunas acciones solo ocurren en determinadas condiciones? Digamos, por ejemplo, entrar en una transacción; solo que el cruce de las medias móviles se decidirá con la ayuda del icono de pregunta:

Figura 3. Algoritmo para entrar en una transacción según el cruce de medias móviles

Cada icono de la condición tendrá siempre dos salidas: una en la parte inferior y otra a la derecha (y solo así). Es decir, cualquier acción en el algoritmo se producirá siempre de arriba abajo y de izquierda a derecha. Las flechas siguen siendo innecesarias. Al comprobar el algoritmo, solo deberemos seguir las líneas hasta llegar al final. Y entonces, normalmente, tendremos que parar.....

A veces ocurre que debemos tomar una decisión sobre la base de tres o más opciones en lugar de dos. Digamos que el usuario pulsa una tecla determinada y, según la tecla que pulse, el programa deberá realizar determinadas acciones. Obviamente, esto se puede dibujar con las preguntas habituales, pero el esquema resultará engorroso.

En este caso, un diseño mejor elegido funcionaría mucho mejor.

Figura 4. Procesamiento de la pulsación de teclas.

Observe que el icono de la última opción se deja en blanco. En el lenguaje MQL, esta opción se corresponde con el operador por defecto, es decir, si no existe otra opción adecuada, se realizará la acción por defecto.

Podrá utilizar este ejemplo para trazar otra regla de DRAKON: todas las ramas verticales irán de izquierda a derecha, y cuanto más a la derecha, peor será la opción. La opción más a la izquierda a veces se denomina "Camino Real" o "Camino Feliz" (happy path).

Si las opciones resultan equivalentes, simplemente se clasificarán según algún criterio. Por ejemplo, nosotros hemos realizado la clasificación según la ubicación de la letra pulsada en el alfabeto.

Sin embargo, es cierto que existe una situación en la que es necesario ir al principio de algún bloque sin llegar al final del programa. Estos son los ciclos MIENTRAS.

Figura 5. Esperamos la señal hasta que aparezca. La acción "Esperar la señal" se realiza al menos una vez en todas las circunstancias.

O se puede reescribir el mismo ciclo para que primero compruebe la condición y luego realice algunas acciones.

Figura 6. Esperamos la señal hasta que aparezca. La acción "Esperar señal" no puede ejecutarse nunca si ya ha llegado una señal.

En cualquier caso, la flecha será ya un elemento necesario aquí, sin ella el esquema se leerá mucho peor.

Y existe otra regla importante sobre los ciclos. El ciclo puede tener las salidas que queramos, pero la entrada solo puede ser una. Es decir, no se puede tender una flecha desde un lugar arbitrario del programa a un lugar arbitrario del ciclo. Siempre deberemos volver al principio.

Esquemas "Silueta" en DRAKON

Como DRAKON es un lenguaje visual, es importante que sus esquemas resulten fáciles de leer. Y para ello, será mejor que todo el esquema quepa en la pantalla (o en la hoja) de una sola pieza.

Este requisito no es siempre realizable, ni mucho menos, pero es algo a lo que debemos aspirar. Otra forma de colocar los iconos del lenguaje puede ayudar a ello: "Silueta".

Una silueta es simplemente una forma de descomponer una función larga en varios componentes, es decir, en pasos de ejecución, pero dejándola como un todo.

Aquí tenemos, por ejemplo, cómo podría ser el procesamiento de ticks en un asesor típico, escrito como una silueta.

Figura 7. La silueta es la segunda configuración básica de los esquemas en el lenguaje DRAKON

En la parte superior de cada rama figurará su nombre convencional en lenguaje humano. En la parte inferior se encontrará la dirección de transición, es decir, hacia dónde se redirigirá el flujo de comandos una vez ejecutada esta rama. Por regla general, la transición se hace a una rama vecina, pero hay casos en que es necesario ir a otro lugar.

Si la transición se encuentra más a la derecha, se ofrecerá simplemente el nombre de la rama.

Si la transición es al principio de la misma rama o a una rama a la izquierda, los marcadores de inicio y fin de las respectivas ramas se marcarán con un triángulo negro:

Figura 8. Ciclo en una rama de la silueta

Si tenemos que usar un ciclo de este tipo, deberemos asegurarnos de que tenga una condición de salida que lleve el programa a otra rama. De lo contrario, el ciclo amenazará con hacerse interminable.

En mis esquemas, intento evitar ciclos así. En los problemas que resuelvo, se puede prescindir de ellos el 95,4% de las veces....

De hecho, la silueta es un esquema de estados. Por regla general, los editores entienden cada rama exactamente de esta manera, como algunos estados del proceso en el momento; de la misma manera interpretan la silueta: como un ciclo infinito con una selección de estados utilizando el operador switch-case en su interior. Por eso necesitamos etiquetas en la entrada y la salida: el programa deberá saber hacia dónde cambiar, y el humano necesitará ver qué fragmento está activo en cada momento.

Solo se puede entrar en una rama por el principio de la misma. La salida de la última rama se realizará a través del icono "fin".

Otros matices de los sistemas DRAKON

Espero que se haya dado cuenta de que en ninguno de los esquemas anteriores se cruzan las líneas si no hay conexión. Se trata de un punto fundamental que aporta claridad a los esquemas. No deben existir cruces. Solo puede haber fusiones de rutas o transiciones por etiquetas. Donde haya un cruce, podrá elegir ese camino cuando la tarea se desplace hacia la solución.

Por cierto, en la figura 7, la rama para añadir posiciones adicionales (tercera por la izquierda) no se ha dibujado correctamente. En el dibujo debería haber el menor número posible de líneas paralelas. Esta norma también añade visibilidad. Por desgracia para mí, Fabula no sabe dibujar bien las ramificaciones, pero no se trata de un error, sino más bien de un error de interpretación.

La excepción a la regla de "movimiento hacia abajo o hacia la derecha" es la línea más baja del esquema que une los pinchos de la silueta en uno solo. Siempre devuelve el proceso al inicio para seleccionar un nuevo estado, así que la seguimos de derecha a izquierda, hacia la flecha.

En principio, casi todos los programas permiten crear varios esquemas en una sola hoja, y a veces puede estar justificado.

Si los esquemas son pequeños, y casi todos serán verticales (y las siluetas pueden hacerse muy compactas)... Y entre los esquemas existe un espacio suficiente (o están bien marcados con color, o mejor aún, con bordes adicionales)... Si se cumplen todas estas condiciones, podremos mejorar la visibilidad de los diagramas cuando se combinen.

Si sus esquemas han sido diseñados para imprimirse en papel, tendrá sentido intentar clasificarlos de la forma más compacta posible, siguiendo las recomendaciones del párrafo anterior.

No obstante, en todos los demás casos, seguirá siendo mejor colocar cada esquema en un espacio aparte, especialmente si existen grandes "siluetas" entre ellos, o si dichos esquemas se han diseñado para imprimirse en papel en blanco y negro. La mayoría de las veces, la esencia de DRAKON es la visibilidad, no la compactibilidad. Precisamente la visibilidad reduce el esfuerzo mental de la comprensión: "¿Qué se ha representado aquí?", y permite canalizar esos esfuerzos hacia el desarrollo de soluciones eficaces.

Importación de esquemas de DRAKON a MQL

Cuando armamos un algoritmo grande y bonito utilizando iconos gráficos, queremos minimizar el esfuerzo que requiere convertir lo dibujado en algo escrito.

Por regla general, utilizamos el editor DRAKON para este fin.

Al abrir el editor, lo primero que debemos hacer es crear un archivo (o abrir uno existente).

Figura 9. Editor DRAKON - Diálogo de creación de archivos

La cuestión es que DRAKON Editor (DE) usa el autoguardado: todos los cambios en la pantalla se guardan inmediatamente en un archivo.

Las letras amarillas de esta ventana indican que, al arrastrar iconos por la pantalla cuando creamos diagramas, podemos utilizar la tecla "Shift": entonces el arrastre se volverá "inteligente".

Vamos a convertir los esquemas dibujados al lenguaje Java. Esta será la opción más sencilla si no nos apetece escribir un analizador sintáctico especial para MQL (a mí sigue sin apetecerme). La estructura de los archivos Java se parece enormemente a la estructura de los programas MQL5, por lo que los archivos generados se compilarán introduciendo algunas modificaciones mínimas.

En la esquina superior izquierda de la ventana principal del programa hay un botón que permite abrir la descripción del archivo y el menú "File", donde también se encuentra esta opción:

Figura 10. Editor DRAKON - Menú y botón de propiedades del archivo

¡La descripción del archivo es funcional!

Además de las explicaciones generales, podemos insertar dos secciones en la descripción, que se trasladarán íntegramente al programa acabado. Aunque todavía no hay nada, dichas secciones tendrán un aspecto muy sencillo:

===header===

===class===
class Main {

Después de la línea "===class===" bastará con escribir las palabras "class Main {". Observe que hay una llave. La segunda llave será añadida por el editor durante la generación.

Solo puede haber una clase en un archivo.

Todo lo que se inserte después de la línea "===header===", el DE lo insertará en su archivo directamente. Por ello, si estamos escribiendo un programa enteramente en el lenguaje DRAKON, deberíamos poner todas las variables globales, instrucciones "#include", descripciones de estructuras y enumeraciones, etc. en esta sección.

Cualquier cosa antes de la sección "===header===" se ignorará. Así que podemos insertar aquí las descripciones de texto que queramos

Si estamos escribiendo un indicador simple, las palabras "class Main {" y la llave que cierra el archivo final deberán ser eliminadas.

No obstante, si entendemos cómo funciona la programación orientada a objetos, podremos utilizar la descripción de la clase justo en la misma cabecera como de costumbre, excluyendo la implementación de funciones. La aplicación de las funciones tendrá lugar en los diagramas. Solo tenga en cuenta que en Java todo es una clase, mientras que MQL todavía tiene funciones que operan en el ámbito global.

Quiero demostrar la creación de un indicador NR4 simple que marque una vela si su tamaño es menor que otras velas delante de él. El número de velas "grandes" se fijará en los parámetros de entrada. A menudo, la aparición de una vela de este tipo indica la probabilidad de un movimiento brusco inminente.

Aquí está el código de nuestra descripción:

===header===
//+------------------------------------------------------------------+
//|                                                          NR4.mq5 |
//|                                       Oleg Fedorov (aka certain) |
//|                                   mailto:[e-mail] |
//+------------------------------------------------------------------+
#property copyright "Oleg Fedorov (aka certain)"
#property link      "mailto:[e-mail]"
#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 {

¡UF! Cerramos la descripción del archivo...

Ahora solo queda una cosa de la configuración: decirle al editor que nuestro archivo debe ser convertido a Java.

Seleccionamos el menú "File -> File properties" y en el cuadro de diálogo que aparecerá elegimos "Java" en la lista de la línea superior.

Figura 11. Selección del lenguaje al que se convertirá el esquema.

Eso es todo, la configuración está completa. Ahora podemos comenzar a programar el algoritmo.

Podemos escribir cualquier texto en los iconos, pero en este caso cada icono contendrá un fragmento de código que irá al archivo final. Si hablamos de una demostración para un cliente, con escribir comentarios en lenguaje humano será suficiente; si queremos almacenar código compilable en diagramas, escribiremos lo que debería suceder con suficiente detalle... Tenemos un segundo caso.

Y, sí, el icono "Insertar" en DE no funciona al compilar, solo debemos usar el icono "Acción".

Tendremos que crear un diagrama diferente para cada función.

El DE lo exige explícitamente (otros editores son más "leales"). No podemos crear varios diagramas aquí sin crear varias entidades para los diagramas utilizando un botón en el panel o el atajo de teclado Ctrl+N.

En mi caso, han resultado ser solo dos funciones: OnInit y OnCalculate. Aquí las tenemos:

Figura 12. Función OnInit

Figura 13. Función OnCalculate

Si el texto de las figuras es demasiado pequeño, descargaremos e instalaremos el DRAKON Editor (el sitio web contiene instrucciones detalladas y describe todas las dependencias). Y luego abriremos directamente el archivo esquemático que he adjuntado como anexo.

Bueno, y después, utilizando el menú "DRAKON -> Generate code" intentaremos convertir el esquema a código compilado. Si hay errores en el esquema (por ejemplo, no hemos tendido una línea hasta otra línea o icono), el DE nos advertirá de ello en el panel de la parte inferior. Si no hay errores, aparecerá un archivo con la extensión *.java en la carpeta que contiene el archivo del proyecto.

Guárdelo en su directorio de indicadores, cambie la extensión a *.mq5, elimine la descripción de la clase si fuera necesario, y después compile y ejecute...

Aquí está el contenido de nuestro archivo antes de eliminar todo el material extra:

// Autogenerated with DRAKON Editor 1.31
//+------------------------------------------------------------------+
//|                                                          NR4.mq5 |
//|                                       Oleg Fedorov (aka certain) |
//|                                   mailto:[e-mail] |
//+------------------------------------------------------------------+
#property copyright "Oleg Fedorov (aka certain)"
#property link      "mailto:[e-mail]"
#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);
    }
}

Permítame recordarle una vez más: para que este sencillo indicador funcione, el texto resaltado en amarillo deberá eliminarse, tanto arriba como abajo. Aquí no hemos utilizado deliberadamente un estilizador, para que el lector pueda juzgar exactamente cómo será formateado su archivo por la automatización del DE.

Leer este código es, por supuesto, mucho más difícil que si lo escribiéramos a mano, pero.... Funciona. Y no hace falta leerlo, bastará con mirar los esquemas. ;-)

Conclusión

Si es usted desarrollador y le gusta DRAKON, no dudes en utilizar cualquiera de las herramientas de creación de diagramas que hemos nombrado anteriormente. Lo mejor es que pruebe por sí mismo cada uno de los editores de la lista y se forme su propia opinión sobre qué es mejor para usted personalmente, y qué es lo peor... En esencia, todos son sencillos.

Si quieres que el cliente haga un pedido, dale un enlace a Dragon.Tech o a drakonhub, explíquele en tres palabras cómo crear un proyecto en lenguaje humano y cómo se relacionan los iconos entre sí, y dígale que estaría bien que describiera con palabras lo que quiere ver. Lo principal es tener una estructura clara.

Si es usted cliente y ha llegado hasta aquí, ya lo tiene claro. ;-)

Entre bastidores, existen todo tipo de temas: el uso de DRAKON en presentaciones interactivas, formas de organizar y estructurar cualquier información para recordar más fácilmente, no solo programas informáticos, así como críticas al lenguaje DRAKON y a todos los lenguajes gráficos...

Si está interesado, escríbanos por mensajes privados o en los comentarios a este artículo y hablaremos de ello. Puede visitar el sitio web de V.D. Parondzhanov y seguir los enlaces que encontrará allí; podrá "desenterrar" muchas otras cosas....

Y espero haber conseguido, al menos de alguna manera, despertar cierto interés por este enfoque y que al menos un par de personas que hayan leído el artículo empiecen a utilizar esta maravillosa herramienta en la práctica.

Si alguien necesita las fuentes de otros algoritmos descritos en este artículo, que me escriba y se las enviaré.

Anexos. El archivo contiene un fichero con el proyecto del DRAKON Editor que contiene el algoritmo del indicador descrito en la sección anterior. A partir de este archivo se puede generar un código completamente funcional del indicador NR4.