Arquitectura Del Sistema De Trading Algorítmico

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 las colas de evento y 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 del 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. TagsAlgorithmic Trading Requisitos del sistema Actualmente estoy tomando una clase sobre arquitecturas de software. Para esta clase cada estudiante elige un sistema, define sus requisitos arquitectónicos y diseña una solución capaz de satisfacer esos requisitos. Elegí un sistema de comercio algorítmico debido al desafío tecnológico y porque me encanta los mercados financieros. Los sistemas de negociación algorítmica (ATs) utilizan algoritmos computacionales para tomar decisiones comerciales, enviar pedidos y administrar pedidos después de la presentación. En los últimos años ATs han ganado popularidad y ahora representan la mayoría de los oficios puestos a través de intercambios internacionales. Distinción se hace entre el comercio programado y el comercio algorítmico. El comercio programado consiste en dividir las órdenes de grandes mercados en paquetes de acciones más pequeñas. En este artículo, el comercio programado se considera un requisito de seguridad de un ATs. Introducción a los sistemas de negociación algorítmica Hablando en general, hay cinco tipos de participantes en el mercado: los inversores minoristas, los comerciantes propietarios, los creadores de mercado, las instituciones de compra y las instituciones de venta. ATs son más utilizados por las instituciones propietarias de buy-side, pero esta dinámica está cambiando. Algorithmic trading as a service (ATAAS) hace que el comercio algorítmico sea accesible al inversor minorista (ver apéndice). En este artículo se describen los requisitos arquitectónicos de un ATs utilizado por una entidad propietaria de buy-side. En la parte superior más nivel, un AT tiene tres funciones: tomar decisiones comerciales, crear órdenes comerciales, y administrar los pedidos después de la presentación. Debajo de estos hay una serie de requisitos funcionales más detallados, algunos de los cuales pueden ser satisfechos por la arquitectura. Introducción a la arquitectura de software Mucho debate aún rodea la definición de lo que es una arquitectura de software. En el contexto de este artículo, la arquitectura de software se define como la infraestructura en la que se pueden especificar, desplegar y ejecutar los componentes de la aplicación que proporcionan la funcionalidad del usuario. Un sistema de software debe satisfacer sus requisitos funcionales y no funcionales. Los requisitos funcionales especifican las funciones de los componentes del sistema. Los requisitos no funcionales especifican las medidas a través de las cuales se mide el rendimiento del sistema. Un sistema de software que satisface sus requisitos funcionales, puede todavía no satisfacer las expectativas del usuario, p. Un ATs que puede presentar oficios, pero no de manera oportuna, podría causar pérdidas financieras. La arquitectura del software básicamente proporciona una infraestructura que satisface los requisitos no funcionales y dentro del cual se pueden implementar y ejecutar componentes que satisfacen requisitos funcionales. Por lo tanto, los requisitos de los sistemas de comercio algorítmicos se pueden dividir ampliamente en requisitos funcionales y no funcionales. Requisitos funcionales Debajo de las decisiones de toma de decisiones nivel superior requisito hay tres requisitos de alto nivel: Obtener datos de mercado - descargar, filtrar y almacenar datos estructurados y no estructurados. Los datos estructurados incluyen datos de mercado en tiempo real de Reuters o Bloomberg transmitidos usando un protocolo, p. FIJAR. Los datos no estructurados incluyen noticias y datos de redes sociales. Definir estrategia de negociación - especificar nuevas reglas y estrategias comerciales. La regla de negociación consiste en un indicador, una desigualdad y un valor numérico, p. PE ratio lt 10. Las reglas de negociación se estructuran en un árbol de decisión para definir una estrategia comercial (ilustrada a continuación). Analizar los valores frente a la estrategia de negociación - para cada seguridad, obtener datos y filtrarlo a través de la estrategia de negociación para determinar qué seguridad comprar. Además: para cada posición abierta, determine qué seguridad vender. Nota: este requisito podría variar. Debajo del requisito de nivel superior de las órdenes comerciales de la demanda allí es dos requisitos de alto nivel: Consiga la información comercial - para cada decisión, consiga el símbolo de la seguridad, el precio, la cantidad, el etc. crea orden comercial - para cada decisión, especifica un tipo de orden y agrega la información comercial . Hay seis tipos de orden: largo, corto, mercado, límite, parada y condicional. Debajo del requisito de alto nivel de órdenes de gestión hay tres requisitos de alto nivel: Gestionar pedidos pendientes - para cada pedido, validar y confirmar el pedido Ruta / enviar pedidos - enrutar cada pedido a un intercambio, piscina oscura o corretaje De cada orden presentada, si la orden es emparejada entonces crea una posición abierta. Si el pedido no coincide, detenga el pedido. Este diagrama muestra cómo una estrategia de negociación podría definirse como un árbol de decisiones de las reglas de comercio. Requisitos no funcionales Existen muchos requisitos no funcionales que se intercambian entre sí, por ejemplo. El mayor rendimiento a menudo se produce con un mayor costo total de propiedad. Los requisitos del sistema de negociación algorítmica no funcional incluyen, Escalabilidad - es la capacidad de un sistema para hacer frente y realizar bajo una carga de trabajo aumentada o en expansión. Un ATs debe ser escalable con respecto al número de feeds de datos en los procesos, número de intercambios que negocia, y los valores que puede negociar. Rendimiento - es la cantidad de trabajo realizado por un sistema en comparación con el tiempo y los recursos necesarios para hacer ese trabajo. Un ATs debe tener tiempos de respuesta rápida (volver al mercado) y un alto procesamiento y rendimiento de la red. Modificabilidad: es la facilidad con la que se puede cambiar el sistema. Un AT debe tener estrategias de negociación fácilmente modificables y procesamiento de datos. Confiabilidad - es la precisión y fiabilidad de un sistema para producir salidas correctas para las entradas que recibe. Debido a errores y errores en un ATs puede dar lugar a enormes pérdidas y multas, la fiabilidad es crucial. Ver la debacle capital Knight para la evidencia de esto. Auditoría - es la facilidad con la que el sistema puede ser auditado. Recientes casos de alto perfil de ATs ir loco han puesto ATs en el centro de atención para las empresas de auditoría. Por lo tanto, deben ser auditables desde el punto de vista financiero, de cumplimiento y de TI. Seguridad - es la seguridad de una organización contra actividades criminales como terrorismo, robo o espionaje. Debido a que las estrategias comerciales son propietarias y representan una valiosa propiedad intelectual, deben ser aseguradas. Además, para proteger a los ATs de la caza, las órdenes deben ser ofuscadas mediante estrategias de negociación programadas. Tolerancia a fallos - es la capacidad de un sistema para seguir funcionando correctamente después de una falla o falla. Esto es similar a la confiabilidad, excepto que los ATs deben seguir siendo confiables incluso después de una falla para evitar pérdidas financieras. Interoperabilidad - es la facilidad con la que el sistema es capaz de operar con una amplia gama de sistemas relacionados. Esto es importante para un ATs que puede ser necesario para interactuar con sistemas de gestión de pedidos, sistemas de gestión de cartera, sistemas de gestión de riesgos, sistemas de contabilidad e incluso sistemas bancarios. Visión general del ámbito arquitectónico El ámbito arquitectónico es el conjunto de servicios soportados por la arquitectura que son consumidos por los componentes para satisfacer sus requisitos funcionales y no funcionales. Un desglose más detallado de este alcance arquitectónico está disponible en el documento detallado de requisitos. En un nivel alto, la arquitectura debería proporcionar los siguientes servicios: Un entorno de procesamiento de datos modificable, que admita múltiples flujos de datos, filtros para datos irrelevantes y partición de datos temporales Un entorno de procesamiento distribuido que admite múltiples unidades de procesamiento (Clusters), monitoreo de rendimiento en tiempo real, un marco de comunicación orientado a mensajes, programación de conjuntos de datos temporales, balanceo de carga y replicación de datos Unidades de procesamiento individuales - que soporta colas en memoria y procesamiento de eventos complejos Un entorno de recuperación de datos (DR) - Replica el SAN y el sistema de gestión de pedidos Un entorno de integración - que expone una API estándar para los componentes y se conecta Componentes internos y externos entre sí Un sistema de gestión de pedidos que soporta corrientes de entrada concurrentes, redundancia pasiva y equilibrio de carga, criterios ACID en órdenes, un rastro de auditoría y se replica Un entorno de uso del sistema que admite varios perfiles de usuario y expone un Completamente gestionado front-end al sistema de comercio algorítmico Requisitos de acceso e integración Requisitos de acceso describen formas en las que los usuarios pueden acceder a los componentes de sistemas. Un sistema de comercio algorítmico debe exponer tres interfaces: una interfaz para definir nuevas reglas comerciales, estrategias de negociación y fuentes de datos; una interfaz de fondo para que los administradores del sistema agreguen clústeres y configuren la arquitectura y una interfaz de auditoría de sólo lectura para comprobar los controles de TI y Derechos de acceso de los usuarios. Los requisitos previos para la integración entre componentes y sistemas externos se denominan requisitos de integración. El sistema de comercio algorítmico debe apoyar la integración basada en archivos, la integración basada en mensajes y la integración de bases de datos. Como tal, la arquitectura debe satisfacer los siguientes requisitos: Integración de base de datos - soporte ODBC, JDBC, ADO y XQC Integración basada en archivos - admite archivos CSV, XML y JSON Integración basada en mensajes - admite FIX. RÁPIDO. Y FIXatdl Restricciones arquitectónicas Los puntos azules muestran las ubicaciones físicas donde se minimiza la latencia de la red y los puntos rojos muestran las ubicaciones físicas de los grandes intercambios financieros. Con el fin de maximizar el rendimiento del sistema de comercio algorítmico, se debe alojar el sistema en ubicaciones que minimizan la latencia de la red. Fuente: prensa abierta del MIT: dspace. mit. edu/handle/1721.1/6285 Las restricciones arquitectónicas son factores que limitan el rendimiento de la arquitectura que se está construyendo. Las dos limitaciones que voy a mencionar aquí son las restricciones físicas de la red, y las restricciones reguladoras. Las restricciones físicas de la red se colocan en un sistema como resultado de las pobres redes de telecomunicaciones. Para mitigar esta limitación, el sistema debe ser construido donde la latencia de red se minimiza. Otra forma de mitigar las restricciones de red es co-localizar el sistema de comercio algorítmico con el intercambio de mercado. Dicho esto, la decisión de co-localizar introduce restricciones adicionales de procesamiento y espacio. Las restricciones reglamentarias se introducen a través de leyes y reglamentos, que son en su mayoría de países y de intercambio específico. Este es un factor cada vez más importante en el diseño y la implementación de un sistema de negociación algorítmica porque el comercio algorítmico se está volviendo más regulado después de la caída del flash 2010. Hablando en general, los ATs deben cumplir al menos las normas de la SEC sobre el cumplimiento e integridad del sistema (SCI), las directrices EMEA para los sistemas de negociación algorítmica, las normas de negociación algorítmica ISO9000 (AT9000) y las normas internacionales de información financiera (IFRS) . Conclusión Las arquitecturas algorítmicas de los sistemas comerciales se complican por los estrictos requisitos no funcionales que se esperan del sistema y por la amplia gama de requisitos reglamentarios y de conformidad que rigen el comercio automatizado. Debido a estas complejidades, se debe considerar cuidadosamente el diseño e implementación de la arquitectura del sistema. Al diseñar una arquitectura de código abierto de algoritmos comerciales espero señalar aquellos requisitos arquitectónicos que a menudo se pasan por alto en el inicio del diseño de tales sistemas. Es improbable que los requisitos identificados en este documento sean completos y evolucionen inevitablemente con el tiempo. La segunda parte de este artículo incluirá mi diseño para una arquitectura de software que cumpla con los requisitos mencionados anteriormente. Para obtener más información sobre el comercio algorítmico, no dude en ponerse en contacto conmigo. Para descargar una copia de mi informe, haga clic aquí. Para obtener una lista completa de fuentes, consulte el informe Apéndice Los proveedores de servicios ATAAS incluyen, pero no están limitados a: Quantopian: los usuarios definen estrategias de negociación cuantitativas en Python y pueden volver a probarlas. Los usuarios también pueden ejecutar esas estrategias en los mercados en vivo. Quantopian recibió recientemente una inversión de 6,7 millones de dólares para ampliar sus servicios. EquaMetrics - usando los usuarios de RIZM construye visualmente nuevas estrategias de negociación algorítmicas, prueba de nuevo esas estrategias y ejecuta esas estrategias en los mercados en vivo. EquaMetrics anunció recientemente nuevos fondos para RIZM valuados en 4,5 millones de dólares. Corretajes: algunas corretajes permiten a los comerciantes crear bots comerciales que ejecutan automáticamente sus estrategias comerciales. TagsSystem Architecture La arquitectura de AlgoTrader se compone de los siguientes componentes. El servidor AlgoTrader proporciona la infraestructura para todas las estrategias que se ejecutan en la parte superior de la misma. El servidor AlgoTrader posee el motor principal de procesamiento de eventos complejos (CEP) de Esper. Es responsable de todos los objetos del modelo de dominio y de su persistencia en la base de datos. Existen diferentes adaptadores de datos de mercado disponibles para procesar datos de mercado en vivo e históricos. En el otro extremo están disponibles adaptadores para diferentes corredores e intercambios de ejecución, los cuales son responsables de realizar pedidos y recibir ejecuciones. AlgoTrader Server también proporciona componentes de negocio para la gestión de cartera, medición de rendimiento, gestión de riesgos, gestión de dinero, tarificación de opciones, conciliación, cobertura de Forex y optimización de parámetros. Además del servidor AlgoTrader se pueden implementar cualquier tipo de estrategias. AlgoTrader tiene una arquitectura basada en eventos que utiliza un motor dedicado de CEP por cada estrategia. Una estrategia puede implementar cualquier número de sentencias Esper de tipo SQL para el análisis de datos basados ​​en el tiempo y la generación de señales. Las sentencias Esper pueden invocar cualquier número de acciones procedimentales, como poner una orden o cerrar una posición, que están codificadas en Java. La combinación de declaraciones Esper y código Java proporciona un enfoque de los mejores mundos. Para la gestión y la supervisión del sistema existen cuatro clientes GUI diferentes. El nuevo AlgoTrader HTML5 Frontend proporciona funciones relacionadas con el comercio como gráficos, pedidos, posiciones y datos del mercado del amplificador. El cliente de AlgoTrader Eclipse es el entorno de desarrollo de estrategia predeterminado. El cliente EsperHQ gestiona el motor Esper CEP. El cliente Grails es un cliente genérico para la gestión de datos de referencia. Para instalaciones productivas y despliegue AlgoTrader utiliza Docker. Presentación de AlgoTrader 3.0 8211 El AlgoTrader más potente aún Apr-07-2016 AlgoTrader 3.0 ha sido lanzado. Esta versión incluye el nuevo HTML5 Frontend, la implementación de un solo clic con Docker, tres algoritmos de ejecución nuevos y un informe de prueba basado en Excel Introducción a AlgoTrader One-Click Installation por Docker Mar-15-2016 AlgoTrader 3.0 introduce las instalaciones de una estrategia de comercio con un clic Docker BILANZ Artikel zum Thema Hochfrequenzhandel Feb-02-2016 AlgoTrader GmbH CEO Andy Flury en Entrevista con BILANZ zum Thema Hochfrequenzhandel Condiciones de la licencia de AlgoTrader LOS TÉRMINOS Y CONDICIONES DE ESTE ACUERDO DE LICENCIA DE USUARIO FINAL (8220AGREEMENT8221) GOBERNAR SU USO DEL SOFTWARE A MENOS QUE USTED Y EL EL LICENCIANTE HA EJECUTADO UN ACUERDO DE LICENCIA ESCRITA SEPARADA QUE RIGE SU USO DEL SOFTWARE. El Licenciante está dispuesto a otorgarle la licencia del Software únicamente bajo la condición de que acepte todos los términos contenidos en este Acuerdo. Al firmar este Acuerdo o descargando, instalando o utilizando el Software, ha indicado que entiende este Acuerdo y acepta todos sus términos. Si no acepta todos los términos de este Acuerdo, el Licenciante no está dispuesto a otorgar la licencia del Software a usted, y no podrá descargar, instalar o utilizar el Software. 1. CONCESIÓN DE LA LICENCIA a. Evaluación Uso y Desarrollo Uso de la Licencia. Sujeta a su cumplimiento de los términos y condiciones de este Acuerdo, el Licenciante le otorga una licencia personal, no exclusiva e intransferible, sin derecho a sublicenciar, durante el plazo de este Contrato, para usar internamente el Software únicamente para Evaluación Uso y Desarrollo Uso. Los productos o módulos de software de terceros suministrados por el Licenciante, si los hubiere, podrán ser utilizados únicamente con el Software y podrán estar sujetos a su aceptación de los términos y condiciones proporcionados por dichos terceros. Cuando termine la licencia, debe dejar de usar el Software y desinstalar todas las instancias. Todos los derechos no específicamente otorgados a usted en este documento son retenidos por el Licenciante. El Desarrollador no hará ningún uso comercial del Software, ni de ningún trabajo derivado del mismo (incluso para propósitos internos del propio Desarrollador). Queda prohibida la copia y redistribución, en cualquier forma, del Software o de la Aplicación para Desarrolladores a sus clientes directos o indirectos. segundo. Licencia de Uso de Producción. Sujeto a su cumplimiento de los términos y condiciones de este Acuerdo incluyendo el pago de la tarifa de licencia aplicable, el Licenciante le otorga una licencia no exclusiva e intransferible, sin el derecho de sublicenciar, por el término de este Acuerdo, a : (A) utilizar y reproducir el Software únicamente para sus propios fines comerciales internos (8220Producción Utilización8221) y (b) hacer un número razonable de copias del Software únicamente con fines de respaldo. Dicha licencia se limita al número específico de CPUs (si está licenciado por la CPU) oa las instancias de Java Virtual Machines (si las licencias por máquina virtual) para las que ha pagado una cuota de licencia. El uso del Software en un mayor número de CPUs o instancias de Java Virtual Machines requerirá el pago de una tarifa de licencia adicional. Los productos de software de terceros o los módulos suministrados por el Licenciante, si los hubiere, podrán ser utilizados únicamente con el Software. do. No hay otros derechos. Sus derechos en y para utilizar el Software están limitados a aquellos expresamente otorgados en esta Sección 1. Usted no hará ningún otro uso del Software. Excepto como expresamente licenciado en esta Sección, el Licenciante no le concede ningún otro derecho o licencia, por implicación, estoppel o de otra manera. TODOS LOS DERECHOS NO EXPRESAMENTE CONCEDIDOS EN EL PRESENTE SON RESERVADOS POR EL LICENCIANTE O SUS PROVEEDORES. 2. RESTRICCIONES Salvo lo expresamente previsto en la Sección 1, usted no: (a) modificará, traducirá, desensamblará, creará trabajos derivados del Software o copiará el Software; (b) alquilará, prestará, transferirá, distribuirá o concederá ningún derecho en el (C) proporcionar, revelar, divulgar o poner a disposición del Software, o permitir el uso del mismo, cualquier tercero (d) publicar cualquier prueba de rendimiento o de referencia que se ejecute en el Software o en cualquier parte del mismo o ( E) eliminar cualquier aviso, etiqueta o marca registrada del Software. Usted no distribuirá el Software a ninguna persona de forma autónoma o con base en un fabricante de equipos originales (OEM). 3. PROPIEDAD Entre las partes, el Software es y seguirá siendo propiedad exclusiva y exclusiva del Licenciante, incluyendo todos los derechos de propiedad intelectual en el mismo. 4. TERMINO a. En el caso de que utilice el Software bajo la licencia establecida en la Sección 1 (a), este Acuerdo permanecerá vigente durante el período de evaluación o desarrollo. segundo. En el caso de que utilice el Software bajo la licencia establecida en la Sección 1 (b), este Contrato permanecerá en vigor (a) por un período de un año si se adquiere como una licencia anual de suscripción o (b) perpetuamente si se adquiere como licencia perpetua. Una licencia anual de suscripción se renovará automáticamente por un año a menos que se termine con un mes de aviso previo. Este Acuerdo terminará automáticamente sin previo aviso si usted incumple cualquier término de este Acuerdo. Al finalizar, usted debe dejar de usar el Software y destruir todas las copias del Software en su posesión o control. 5. SERVICIOS DE APOYO Si ha adquirido esta licencia incluyendo Servicios de Soporte, éstos incluyen Actualizaciones de Mantenimiento (Actualizaciones y Actualizaciones), soporte telefónico y soporte por correo electrónico o web. a. El Licenciante hará esfuerzos comercialmente razonables para proporcionar una Actualización diseñada para resolver o evitar un Error reportado. Si dicho error se ha corregido en una versión de mantenimiento, el Licenciatario debe instalar e implementar el Release de Mantenimiento aplicable, de lo contrario, la Actualización puede proporcionarse en forma de una corrección temporal, procedimiento o rutina, está disponible. segundo. Durante el Período del Contrato de Licencia, el Licenciante pondrá a disposición de los Licenciatarios las Versiones de Mantenimiento si, en la medida en que el Licenciante realice dichas Versiones de Mantenimiento a disposición de sus clientes. Si se plantea la cuestión de si una oferta de producto es una actualización o un nuevo producto o función, prevalecerá la opinión del Licenciante82, siempre que el Licenciante considere la oferta del producto como un nuevo producto o característica para sus clientes usuarios finales en general. do. La obligación del Licenciador82 de proporcionar Servicios de Apoyo está condicionada a lo siguiente: (a) El Licenciatario hace esfuerzos razonables para corregir el Error después de consultar con el Licenciante (b) El Licenciatario proporciona al Licenciante suficiente información y recursos para corregir el Error en el sitio del Licenciador (C) el Licenciatario instala rápidamente todas las Versiones de Mantenimiento y (d) el Licenciatario adquiere, instala y mantiene todo el equipo, la comunicación o el acceso al sitio Web del Licenciatario, así como el acceso al personal, hardware y cualquier software adicional involucrado en el descubrimiento Interfaces y otro hardware necesario para operar el Producto. re. El Licenciante no está obligado a prestar Servicios de Apoyo en las siguientes situaciones: (a) el Producto ha sido modificado, modificado o dañado (excepto si bajo la supervisión directa del Licenciante) (b) el Error es causado por negligencia del Licenciatario, U otras causas fuera del control razonable del Licenciador (c) el Error es causado por software de terceros no licenciado a través del Licenciador (d) El Licenciatario no ha instalado e implementado el (los) Release (s) de Mantenimiento para que el Producto sea una versión soportada por el Licenciante o (e) El Licenciatario no ha pagado los honorarios de la Licencia o los honorarios de los Servicios de Apoyo cuando esté vencido. Además, el Licenciante no está obligado a proporcionar Servicios de Soporte para el código de software escrito por el propio cliente basado en el Producto. mi. El Licenciante se reserva el derecho de descontinuar los Servicios de Soporte si el Licenciante, a su sola discreción, determina que el soporte continuo para cualquier Producto ya no es económicamente factible. El Licenciante otorgará al Licenciatario por lo menos tres (3) meses de antelación un aviso por escrito de cualquier discontinuación de los Servicios de Apoyo y reembolsará cualquier cargo de Servicios de Apoyo no acumulado que el Licenciatario pueda haber pagado con anticipación con respecto al Producto afectado. El Licenciante no tiene ninguna obligación de soportar o mantener ninguna versión del Producto o las plataformas de terceros subyacentes (incluyendo pero no limitado a software, JVM, sistema operativo o hardware) para el cual se admite el Producto excepto (i) la versión actual de la El producto y la plataforma de terceros subyacente, y (ii) las dos versiones inmediatamente anteriores del producto y del sistema operativo durante un período de seis (6) meses después de su sustitución. El Licenciante se reserva el derecho de suspender la ejecución de los Servicios de Apoyo si el Licenciatario no paga cualquier monto que sea pagadero al Licenciante bajo el Contrato dentro de los treinta (30) días después de que dicha cantidad venza. 6. GARANTÍA a. El Licenciante garantiza que el Software será capaz de realizar en todos los aspectos materiales de acuerdo con las especificaciones funcionales establecidas en la documentación aplicable durante un período de 90 días después de la fecha en que instale el Software. En caso de incumplimiento de dicha garantía, el Licenciante deberá, a su elección, corregir el Software o reemplazarlo gratuitamente. Lo anterior son sus únicos y exclusivos recursos y la única responsabilidad del Licenciante por incumplimiento de estas garantías. Las garantías establecidas anteriormente se hacen a favor de usted. Las garantías se aplicarán únicamente si (a) el Software ha sido instalado y utilizado correctamente en todo momento y de acuerdo con las instrucciones de uso (c) las últimas actualizaciones se han aplicado al software y (c) ninguna modificación, alteración o adición Ha sido hecha al Software por personas que no sean el Licenciante o el representante autorizado del Licenciante. 7. EXENCIÓN DE RESPONSABILIDAD EXCEPTO LO QUE SE PUEDE PROPORCIONAR EN VIRTUD DE LA SECCIÓN 6 (a), EL LICENCIANTE RENUNCIA EXPRESAMENTE A TODAS LAS GARANTÍAS, EXPRESAS O IMPLÍCITAS, INCLUIDAS CUALQUIER GARANTÍA IMPLÍCITA DE COMERCIABILIDAD, ADECUACIÓN PARA UN PROPÓSITO ESPECÍFICO Y NO INFRACCIÓN Y CUALQUIER GARANTÍA RESULTANTE DEL TRATAMIENTO O USO DEL COMERCIO. NINGÚN CONSEJO O INFORMACIÓN, YA SEA ORAL O ESCRITO, OBTENIDO DEL LICENCIANTE O EN CUALQUIER OTRA PARTE CREARÁ CUALQUIER GARANTÍA NO EXPRESAMENTE ESTABLECIDA EN ESTE ACUERDO. El Licenciante no garantiza que el Producto de Software cumpla con sus requisitos o que funcione bajo sus condiciones específicas de uso. El Licenciante no garantiza que el funcionamiento del Producto de Software sea seguro, libre de errores o libre de interrupciones. USTED DEBE DETERMINAR SI EL PRODUCTO DE SOFTWARE SEA SUFICIENTEMENTE CONFORME A SUS REQUISITOS DE SEGURIDAD E ININTERRUPTABILIDAD. USTED ES LA ÚNICA RESPONSABILIDAD Y TODA RESPONSABILIDAD POR CUALQUIER PÉRDIDA INCURRIDA POR FALLO DEL PRODUCTO DE SOFTWARE PARA CUMPLIR CON SUS REQUISITOS. EL LICENCIANTE NO SERÁ RESPONSABLE O RESPONSABLE POR NINGUNA CIRCUNSTANCIA POR LA PÉRDIDA DE DATOS EN CUALQUIER COMPUTADOR O DISPOSITIVO DE ALMACENAMIENTO DE INFORMACIÓN. 8. LIMITACIÓN DE RESPONSABILIDAD LA RESPONSABILIDAD TOTAL DE LICENSOR8217S A USTED DE TODAS LAS CAUSAS DE ACCIÓN Y BAJO TODAS LAS TEORÍAS DE RESPONSABILIDAD ESTARÁ LIMITADA Y NO EXCEDERÁ LA CUOTA DE LICENCIA PAGADA POR USTED AL LICENCIANTE DEL SOFTWARE. EN NINGÚN CASO, EL LICENCIANTE SERÁ RESPONSABLE ANTE USTED POR CUALQUIER DAÑO ESPECIAL, INCIDENTAL, EJEMPLAR, PUNITIVO O CONSECUENTE (INCLUYENDO PÉRDIDA DE USO, DATOS, NEGOCIOS O BENEFICIOS) O POR EL COSTE DE PROCURAR PRODUCTOS SUBSTITUTIVOS RESULTANTES O EN CONEXIÓN CON ESTE ACUERDO O EL USO O EL DESEMPEÑO DEL SOFTWARE, YA SEA DICHA RESPONSABILIDAD DERIVADA DE CUALQUIER RECLAMACIÓN BASADA EN CONTRATO, GARANTÍA, AGRAVIO (INCLUIDA NEGLIGENCIA), RESPONSABILIDAD ESTRICTA O DE OTRA MANERA, Y SI EL LICENCIANTE HA SIDO AVISADO DE LA POSIBILIDAD DE TALES PÉRDIDAS O DAÑAR. LAS LIMITACIONES ANTERIORES SOBREVIVIRÁN Y SE APLICARÁN AUNQUE CUALQUIER RECURSO LIMITADO ESPECIFICADO EN ESTE ACUERDO SE ENCONTRARÁ QUE HAYA FALTADO SU PROPÓSITO ESENCIAL. EN LA MEDIDA EN QUE LA JURISDICCIÓN APLICABLE LIMITA LA CAPACIDAD DE LA LICENCIADORA DE EXCLUIR CUALQUIER GARANTÍA IMPLÍCITA, ESTA EXONERACIÓN DE RESPONSABILIDAD SERÁ EFECTIVA EN LA MEDIDA MÁXIMA PERMITIDA. 9. GENERALIDADES Si alguna disposición de este Acuerdo se considera inválida o inaplicable, el resto de este Acuerdo permanecerá en pleno vigor y efecto. En la medida en que las leyes aplicables no permitan restricciones expresas o implícitas, estas restricciones expresas o implícitas permanecerán en vigor y efecto hasta el máximo permitido por dichas leyes aplicables. Este Acuerdo es el acuerdo completo y exclusivo entre las partes con respecto al objeto del mismo, reemplazando todos y cada uno de los acuerdos previos, comunicaciones y entendimientos (tanto escritos como orales) relacionados con el objeto de este documento. Las partes en este Acuerdo son contratistas independientes, y ninguno tiene el poder de obligar al otro o incurrir en obligaciones por cuenta del otro. Ningún fallo de ninguna de las partes para ejercer o hacer valer ninguno de sus derechos bajo este Acuerdo actuará como una renuncia a tales derechos. Cualquier término o condición contenida en cualquier orden de compra u otro documento de pedido que sea incompatible con o además de los términos y condiciones de este Contrato, es rechazado por el Licenciante y será considerado nulo y sin efecto. Este Acuerdo será interpretado e interpretado de acuerdo con las leyes de Suiza, sin tener en cuenta los principios de conflicto de leyes. Las partes por la presente autorizan la jurisdicción exclusiva y el lugar de los tribunales situados en Zurich, Suiza para la resolución de cualquier disputa que surja o que se relacione con este Acuerdo. 10. DEFINICIONES 8220Evaluación El uso8221 significa el uso del Software únicamente para evaluación y prueba para nuevas aplicaciones destinadas a su Uso de Producción. 8220Producción Use8221 significa usar el Software sólo para fines comerciales internos. Producción El uso no incluye el derecho de reproducir el Software para la sublicencia, revenda o distribución, incluyendo, sin limitación, la operación de compartir el tiempo o distribuir el Software como parte de un acuerdo de ASP, VAR, OEM, distribuidor o revendedor. 8220Software8221 significa el software Licensor8217s y todos sus componentes, documentación y ejemplos incluidos por el Licenciante. 8220Error8221 significa (a) que el Producto no cumple con las especificaciones establecidas en la documentación, lo que da como resultado la incapacidad para usar o restringir el uso del Producto y / o (b) un problema que requiere nuevos procedimientos , Aclaraciones, información adicional y / o solicitudes de mejora de productos. 8220Mantenimiento Release8221 significa actualizaciones y actualizaciones del producto que se ponen a disposición de los licenciatarios de conformidad con los servicios de soporte estándar definidos en la sección 5. 8220Update8221 significa una modificación o adición del software que, cuando se hace o agrega al producto, corrige el error o Procedimiento o rutina que, cuando se observa en el funcionamiento regular del Producto, elimina el efecto adverso práctico del Error en el Licenciatario. 8220Upgrade8221 significa una revisión del Producto lanzada por el Licenciante a sus clientes usuarios finales en general, durante el Término de Servicios de Soporte, para agregar funciones nuevas y diferentes o para aumentar la capacidad del Producto. La actualización no incluye el lanzamiento de un nuevo producto o características adicionales para las que puede haber un cargo por separado.