Funcionalidad Del Sistema De Trading

Algorithmic Trading System Architecture Anteriormente en este blog he escrito sobre la arquitectura conceptual de un sistema de negociación algorítmica inteligente, así como los requisitos funcionales y no funcionales de un sistema de trading algorítmico de producción. Desde entonces he diseñado una arquitectura de sistema que creo que podría satisfacer los requisitos arquitectónicos. En este post describiré la arquitectura siguiendo las directrices de los estándares ISO / IEC / IEEE 42010 y el estándar de descripción de arquitectura de ingeniería de software. De acuerdo con esta norma, una descripción de la arquitectura debe: • Contener múltiples vistas estandarizadas de arquitectura (por ejemplo, en UML) y • Mantener la trazabilidad entre las decisiones de diseño y los requisitos arquitectónicos Definición de la arquitectura de software Todavía no hay consenso sobre lo que es una arquitectura de sistemas. En el contexto de este artículo, se define como la infraestructura dentro de la cual se pueden especificar, desplegar y ejecutar componentes de aplicación que satisfacen requisitos funcionales. Los requisitos funcionales son las funciones esperadas del sistema y sus componentes. Los requisitos no funcionales son medidas a través de las cuales se puede medir la calidad del sistema. Un sistema que satisface plenamente sus requisitos funcionales puede todavía no satisfacer las expectativas si los requisitos no funcionales se dejan insatisfechos. Para ilustrar este concepto, considere el siguiente escenario: un sistema de negociación algorítmico que acaba de adquirir / construye hace excelentes decisiones comerciales, pero es completamente inoperable con las organizaciones de gestión de riesgos y sistemas de contabilidad. Este sistema satisface sus expectativas Arquitectura Conceptual Una visión conceptual describe conceptos y mecanismos de alto nivel que existen en el sistema en el nivel más alto de granularidad. A este nivel, el sistema de comercio algorítmico sigue una arquitectura impulsada por eventos (EDA) dividida en cuatro capas, y dos aspectos arquitectónicos. Para cada capa y aspecto se utilizan arquitecturas y patrones de referencia. Los patrones arquitectónicos son estructuras probadas y genéricas para lograr requisitos específicos. Los aspectos arquitectónicos son preocupaciones transversales que abarcan múltiples componentes. Arquitectura impulsada por eventos: una arquitectura que produce, detecta, consume y reacciona ante eventos. Los eventos incluyen movimientos del mercado en tiempo real, eventos o tendencias complejas y eventos comerciales, p. Presentar una orden. Este diagrama ilustra la arquitectura conceptual del sistema de comercio algorítmico. Arquitectura de referencia Para utilizar una analogía, una arquitectura de referencia es similar a los planos para una pared portante. Esta impresión azul puede ser reutilizada para diseños de edificios múltiples, independientemente de qué edificio se está construyendo, ya que satisface un conjunto de requisitos comunes. De manera similar, una arquitectura de referencia define una plantilla que contiene estructuras genéricas y mecanismos que pueden usarse para construir una arquitectura de software concreta que satisface requisitos específicos. La arquitectura para el sistema de comercio algorítmico utiliza una arquitectura basada en el espacio (SBA) y un controlador de vista de modelo (MVC) como referencias. También se utilizan buenas prácticas, como el almacén de datos operativos (ODS), el patrón de transformación y carga de extracciones (ETL) y un almacén de datos (DW). Controlador de vista de modelo: un patrón que separa la representación de la información de la interacción del usuario con ella. Arquitectura basada en el espacio: especifica una infraestructura en la que las unidades de procesamiento ligeramente acopladas interactúan entre sí a través de una memoria asociativa compartida llamada espacio (se muestra a continuación). Vista estructural La vista estructural de una arquitectura muestra los componentes y subcomponentes del sistema de negociación algorítmica. También muestra cómo se implementan estos componentes en la infraestructura física. Los diagramas UML utilizados en esta vista incluyen diagramas de componentes y diagramas de implementación. A continuación se muestra la galería de los diagramas de despliegue del sistema de negociación algorítmica global y las unidades de procesamiento en la arquitectura de referencia SBA, así como diagramas de componentes relacionados para cada una de las capas. Tácticas arquitectónicas Según el instituto de ingeniería de software una táctica arquitectónica es un medio de satisfacer un requisito de calidad mediante la manipulación de algunos aspectos de un modelo de atributos de calidad a través de decisiones de diseño arquitectónico. Un ejemplo sencillo utilizado en la arquitectura del sistema de negociación algorítmica es la manipulación de un almacén de datos operativos (ODS) con un componente de consulta continua. Este componente analizaría continuamente las ODS para identificar y extraer eventos complejos. Las siguientes tácticas se utilizan en la arquitectura: El patrón disruptor en el evento y las colas de orden Memoria compartida para el evento y colas de orden Lenguaje de consulta continua (CQL) en el ODS Filtrado de datos con el patrón de diseño de filtro en los datos entrantes Algoritmos de evitación de congestión en todos (AQM) y notificación de congestión explícita Recursos de computación de productos básicos con capacidad de actualización (escalable) Redundancia activa para todos los puntos de fallo individuales Indexación y estructuras de persistencia optimizadas en el ODS Programar los scripts regulares de copia de seguridad y limpieza de datos ODS Historial de transacciones en todas las bases de datos Checksums para todos los pedidos para detectar fallos Anotar eventos con marcas de tiempo para omitir eventos antiguos Reglas de validación de orden, por ejemplo Cantidades máximas de comercio Componentes automatizados de comerciantes utilizan una base de datos en memoria para el análisis Autenticación de dos etapas para interfaces de usuario que se conectan a los ATs Cifrado en interfaces de usuario y conexiones a los ATs Patrón de diseño de observador para MVC para gestionar vistas La lista anterior son sólo unos pocos diseño Decisiones que identifiqué durante el diseño de la arquitectura. No es una lista completa de tácticas. A medida que se está desarrollando el sistema, se deben emplear tácticas adicionales a través de múltiples niveles de granularidad para satisfacer requisitos funcionales y no funcionales. A continuación se muestran tres diagramas que describen el patrón de diseño del disruptor, el patrón de diseño del filtro y el componente de consulta continua. Vista de Comportamiento Esta vista de una arquitectura muestra cómo los componentes y las capas deben interactuar entre sí. Esto es útil cuando se crean escenarios para probar diseños de arquitectura y para entender el sistema de extremo a extremo. Esta vista consiste en diagramas de secuencia y diagramas de actividad. Los diagramas de actividad que muestran el proceso interno de los sistemas de negociación algorítmica y cómo se supone que los comerciantes interactúan con el sistema de comercio algorítmico se muestran a continuación. Tecnologías y marcos El paso final en el diseño de una arquitectura de software es identificar posibles tecnologías y marcos que podrían ser utilizados para realizar la arquitectura. Como principio general es mejor aprovechar las tecnologías existentes, siempre que satisfagan adecuadamente los requisitos tanto funcionales como no funcionales. Un marco es una arquitectura de referencia realizada, p. JBoss es un framework que realiza la arquitectura de referencia JEE. Las siguientes tecnologías y marcos son interesantes y deben ser considerados al implementar un sistema de trading algorítmico: CUDA - NVidia tiene una serie de productos que soportan el modelado de finanzas computacionales de alto rendimiento. Uno puede lograr hasta 50x mejoras de rendimiento en la ejecución de simulaciones de Monte Carlo en la GPU en lugar de la CPU. Apache River - River es un kit de herramientas usado para desarrollar sistemas distribuidos. Se ha utilizado como un marco para la construcción de aplicaciones basadas en el patrón SBA Apache Hadoop - en el caso de que el registro generalizado es un requisito, entonces el uso de Hadoop ofrece una solución interesante para el problema de los grandes datos. Hadoop se puede implementar en un entorno de clúster que admita tecnologías CUDA. AlgoTrader - una plataforma de trading algorítmica de código abierto. AlgoTrader podría potencialmente ser desplegado en el lugar de los componentes automatizados del comerciante. FIX Engine - una aplicación independiente que admite los protocolos de intercambio de información financiera (FIX) incluyendo FIX, FAST y FIXatdl. Aunque no es una tecnología o un marco, los componentes deben ser construidos con una interfaz de programación de aplicaciones (API) para mejorar la interoperabilidad del sistema y sus componentes. Conclusión La arquitectura propuesta ha sido diseñada para satisfacer requisitos muy genéricos identificados para los sistemas de negociación algorítmica. En general, los sistemas de negociación algorítmica se complican por tres factores que varían con cada implementación: Dependencias de la empresa externa y sistemas de intercambio Desafiar los requisitos no funcionales y Evolucionar restricciones arquitectónicas Por lo tanto, la arquitectura de software propuesta debe adaptarse caso por caso para Para satisfacer requisitos organizativos y normativos específicos, así como para superar las limitaciones regionales. La arquitectura del sistema de trading algorítmico debe ser visto como un punto de referencia para individuos y organizaciones que desean diseñar sus propios sistemas de trading algorítmicos. Para obtener una copia completa y las fuentes utilizadas, descargue una copia de mi informe. Gracias. TagsOther Trading System Funcionalidad En la puesta en marcha del servidor, los servicios básicos se iniciará: Servlet Container (Tomcat) Confirmar proveedor JMS está activo (ActiveMQ) Servicio de usuario Cuenta Servicio Estrategia Servicio (escanear base de datos para estrategias de carga) Metrics Servicio de Riesgo de Servicio Servicio de Comunicaciones Servicio de Autenticación (autenticación y autorización) Servicio de Auditoría Ejecutar cada XX minutos. Compare la cantidad de la orden con la cantidad de la transacción y la alerta si es diferente. Deberá ejecutarse en el inicio para determinar si hay problemas. A intervalos regulares, la cantidad de la cuenta debe ser conciliada con las cantidades de la transacción. El inicio de las estrategias seguirá este flujo general: Escanee la tabla de strategyrun para estrategias con su carga establecida en true. Existe una posición en la tabla de posiciones Iterate a través de la tabla de posiciones correspondiente a este id de ejecución, y suma las cantidades para cada opción de seguridad en la tabla positiondetails. Hacer todas las cantidades 0 - gt sí - entonces se activará en el estado create-new-trade no - entonces se activará en el estado de gestión. Es el comercio completo --gt sí - gestionar el comercio completo no - determinar qué componentes deben ser construidos y continuar la construcción de comercio - enviar alerta - el comercio incompleto El StrategyService envía órdenes a OrderService. Y el OrderService recibe los rellenos y el estado del pedido del broker. Estas órdenes están asociadas con un strategyrunid y un positionid, que puede ser resuelto a una cuenta, userid y estrategia. Cuando se produce un relleno, el TransactionService crea una entrada en la tabla de transacciones. Se envía una alerta de relleno a través de JMS al StrategyService. El StrategyService llamará a PositionService para actualizar la tabla positiondetails. El StrategyService también actualizará su mapa de posiciones desde el db solicitando una lista actualizada de posiciones del PositionService. En el modo backtest, un pedido se convierte automáticamente en una transacción. Las alertas de estado del pedido son enviadas por OrderService al StrategyService. Una estrategia puede actuar en una actualización del estado de la orden cancelando o reemplazando órdenes. La tabla de resumen se actualiza al cierre del comercio. La tabla de los tradedetailsbyday se pone al día diariamente. Estas actualizaciones son manejadas por el MetricsService. Además, la interfaz de usuario basada en navegador proporcionará la siguiente funcionalidad: Descripción general de la cuenta Puede ver los pedidos asociados con la cuenta Puede ver los rellenos asociados Con la cuenta Puede ver las transacciones asociadas con la cuenta Puede ver todos los valores en la cuenta Puede ver el saldo de efectivo actual en la cuenta Visión general del sistema Posiciones y / o transacciones por tipo o nombre de estrategia Posiciones y / Cuenta, entonces la estrategia, etc ESTE SITIO WEB ES PARA EDUCACION Y / O ENTRETENIMIENTO PROPÓSITOS SOLAMENTE. LA INFORMACIÓN Y ANÁLISIS DE ESTE SITIO SE PROPORCIONAN PARA FINES DE INFORMACIÓN SÓLO. NADA AQUÍ SE DEBE INTERPRETAR COMO CONSEJO DE INVERSIÓN PERSONALIZADA. BAJO NINGUNA CIRCUNSTANCIA ESTA INFORMACIÓN REPRESENTA UNA RECOMENDACIÓN PARA COMPRAR, VENDER O SOSTENER CUALQUIER SEGURIDAD. EL RENDIMIENTO ANTERIOR NO ES NECESARIAMENTE INDICATIVO DE LOS RESULTADOS FUTUROS Y TODAS LAS INVERSIONES INVOLUCRAN EL RIESGO. NO SE REALIZA REPRESENTACIÓN QUE CUALQUIER CUENTA ALCANZA RESULTADOS SIMILARES A LOS MOSTRADOS. NINGUNA DE LA INFORMACIÓN EN ESTE SITIO ES GARANTIZADA DE SER CORRECTA, Y CUALQUIER COSA ESCRITA AQUÍ DEBE ESTAR SUJETA A LA VERIFICACIÓN INDEPENDIENTE. UN SISTEMA DE COMERCIO Un sistema de comercio es una herramienta utilizada por los comerciantes que utiliza criterios de entrada y salida objetivos basados ​​en parámetros que han sido determinados por pruebas históricas en datos cuantificables . Los sistemas se ejecutan en computadoras o servidores y están vinculados a un intercambio para el comercio. Los desarrolladores enviarán revisiones de sistemas (actualizaciones) como mejor les parezca. Por qué debería negociar un sistema de comercio de los mercados de futuros utilizando un sistema de comercio proporciona la disciplina para superar el miedo y la codicia que en muchos casos paraliza a un comerciante y evitar tomar decisiones oportunas. Cada orden colocada se rige por un conjunto predeterminado de reglas que no se desvía basándose en otra cosa que en la acción del mercado. Qué debo considerar Como todo tipo de herramientas, los sistemas de comercio si no se utiliza correctamente, puede ser peligroso para los comerciantes de la salud económica. El comerciante debe evaluar la tolerancia a los futuros de alto riesgo de comercio, el capital de riesgo y la capacidad de soportar la retirada de capital, así como el costo en términos de tiempo y dinero para el comercio en los mercados de futuros. Cómo puedo saber si el sistema es bueno? Uno de los elementos clave de un sistema de comercio es la capacidad de un sistema de comercio a celebrar con el tiempo. Animamos a los clientes a tomar su tiempo y estudiar los resultados antes de abrir una cuenta comercial. La única prueba real de un sistema es ver cómo se realiza en el comercio real donde el deslizamiento del mercado y el costo de negociación son una parte del registro. Cuánto dinero necesito? El depósito mínimo para abrir una cuenta de operaciones de futuros varía dependiendo del sistema de comercio. Además, el posible operador sólo debe considerar la apertura de una cuenta de futuros cuando el comerciante tiene suficiente capital de riesgo, debido al apalancamiento en el comercio de futuros. Cómo empezar? El primer paso es para el comerciante a sus corredores con el fin de comprender el riesgo, así como las recompensas de los futuros de comercio con sistemas de negociación. Si el operador opta por proceder, entonces el siguiente paso es abrir una cuenta de operaciones y seleccionar el sistema de negociación que mejor se adapte a los comerciantes de tolerancias de riesgo personal y los objetivos comerciales. Cuáles son los riesgos Cualquier sistema puede estar sujeto a riesgos específicos del mercado, específicos del sistema o complejos. Al comercializar múltiples sistemas en diferentes mercados, se puede reducir el riesgo específico del mercado y el riesgo específico complejo. Al negociar sistemas con diferentes estrategias de entrada y salida, el operador puede reducir el riesgo específico del sistema. Sin embargo, el riesgo de negociación puede ser sustancial y cada inversor y / o comerciante debe considerar si se trata de una inversión adecuada. El rendimiento pasado no es necesariamente indicativa de resultados futuros.