Discusión sobre el artículo "Experto comercial universal: Modelo de eventos y prototipo de estrategia comercial (Parte 2)"
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Artículo publicado Experto comercial universal: Modelo de eventos y prototipo de estrategia comercial (Parte 2):
Este artículo continúa con la serie de comentarios dedicados al modelo universal de expertos. En esta parte se describe un modelo original de eventos basado en el procesamiento centralizado de datos, y también se estudia la estructura de la clase básica del motor CStrategy.
Este artículo continúa la presentación a los lectores del motor comercial universal CStrategy. En el primer artículo Experto comercial universal: Los modos comerciales de las estrategias (Parte 1) se analizaron con detalle los modos comerciales y las funciones que los organizan. Se propuso un esquema universal de expertos, que consta de cuatro métodos, dos de los cuales abren nuevas posiciones, mientras que los otros dos las cierran. Una combinación diversa en la llamada de estos métodos determina la presencia de uno u otro modo comercial, por ejemplo, para un experto así se puede establecer un modo solo de compras o solo de ventas, el acompañamiento de las posiciones abiertas con anterioridad o el modo espera. Gracias a estos modos, el experto adquiere la posibilidad de ajustar de manera flexible su funcionamiento, dependiendo de la hora comercial o incluso del día de la semana.
Sin embargo, los modos comerciales no son, ni mucho menos, lo único que puede necesitar un experto comercial. En esta segunda parte de la serie de artículos, hablaremos sobre el modelo de eventos del motor comercial CStrategy, basado en el procesamiento centralizado de eventos. El esquema de procesamiento propuesto se distingue de los eventos de sistema precisamente en que todos los eventos se reúnen en un sitio. Hablaremos más abajo de las ventajas que proporciona tal organización.
Asimismo, en esta artículo se describen las dos clases más importantes de todo el motor comercial: son las clases CStrategy y CPosition. La primera de ellas constituye el núcleo de la lógica comercial del experto, ya que une los eventos y los modos en una única carcasa flexible, que heredará directamente el experto del usuario. La segunda clase es la base de la operaciones comerciales universales. En él se ubican las acciones con las posiciones abiertas (por ejemplo, el cierre de posición o el cambio de su nivel de Stop Loss o Take Profit). Gracias a esto, todas las acciones comerciales se convierten en acciones de un solo tipo e independientes de la plataforma.
Acceso a los eventos sucedidos en otros instrumentos, estructura MarketEvent
Al proyectar un sistema comercial que analiza a la vez varios instrumentos, normalmente es necesario un mecanismo que realice el seguimiento del cambio de los precios en varios instrumentos. Sin embargo, la función estándar OnTick se llama solo en el momento de llegada de un nuevo tick en el instrumento en el que ha sido iniciado el experto. Por otra parte, a la disposición de los manejadores de los sistemas comerciales se encuentra la función OnBookEvent. A diferencia de OnTick, la función OnBookEvent se invoca al cambiar la profundidad de mercado del instrumento al que se realizó la suscripción con la ayuda de la función MarketBookAdd.
El cambio de la profundidad de mercado es un evento muy frecuente, y por eso el seguimiento de semejante evento es un procedimiento que exige el gasto de muchos recursos. Normalmente, al experto le basta con realizar un seguimiento de los cambios del flujo de ticks en otros instrumentos. Por otra parte, el evento de cambio en la profundidad de mercado incluye también la llegada de un nuevo tick. Aparte de OnBookEvent, se puede ajustar con cierta periodicidad la llamada OnTimer y ya analizar en esta función los precios cambiados de varios instrumentos.
De esta forma, en las funciones de sistema que reaccionan a los eventos NewTick, BookEvent y Timer, se puede ubicar la llamada de un cierto módulo intermedio (lo llamaremos de forma convencional EventProcessor), que a su vez analizaría el cambio de los precios en varios instrumentos simultáneamente y generaría este u otro evento. Cada evento tendría una descripción unificada en forma de estructura y se enviaría a los métodos de gestión de la estrategia. La estrategia, tras recibir el evento correspondiente en forma de estructura, reaccionaría a él o lo dejaría pasar. En este caso, además, la función de sistema, que sería prácticamente la iniciadora de este evento para el experto final, permanecería desconocida.
En realidad, si el experto ha recibido una notificación sobre la llegada de un nuevo tick, entonces da igual cómo haya sido recibida la información: si a través de OnTick, OnTimer o OnBookEvent. Solo importa que el nuevo tick para el instrumento indicado haya llegado. El manejador de eventos puede ser uno para varias estrategias. Por ejemplo, si cada estrategia la presentamos en forma de clase de usuario, entonces se pueden guardar de golpe varios ejemplares de esta clase en una lista especial de estrategias. Además, cada una de las estrategias de la lista tendría la posibilidad de recibir un nuevo evento, generado por el módulo EventProcessor. Presentamos de forma esquemática el modelo de creación y distribución de eventos en el siguiente gráfico:
Fig. 1. Esquema del modelo de creación y distribución de eventos
Autor: Vasiliy Sokolov