Trading en Soleres-HCI​

Contenido​

1. Perspectiva de la arquitectura basada en modelos
2. Metamodelo CIM: Trader
3. Modelo CIM: Trader
4. Metamodelo PIM: diagrama de clases informal
5. Modelo PIM: diagrama de clases informal del trader
6. Transformación de modelo a modelo
   6.1. Transformación del trader
   6.2. Transformación de la interfaz Lookup
   6.3. Transformación de la interfaz Register
   6.4. Transformación de la interfaz Admin
   6.5. Transformación de la interfaz Link
   6.6. Transformación de la interfaz Proxy
7. Transformación de modelo a texto
   7.1. Transformación de clases

Perspectiva de la arquitectura basada en modelos​

Para implementar el agente trader, seguimos una perspectiva de Ingeniería Dirigida por Modelos (MDE) basada en la Arquitectura Dirigida por Modelos (MDA) clásica de la OMG. En esta perspectiva, el modelo del agente trader permanece las tres etapas de la MDA: CIM/PIM/PSM (véase la Figura 1). Para cada etapa se define un metamodelo de operador (MM), que describe la forma de generar un modelo diagramatical (UML) del operador.

Figura 1: Pasos del MDA de las vistas de los traders

Metamodelo CIM: Trader​

La figura 2 muestra el metamodelo del trader. Sólo muestra los conceptos -Trader (con sus parámetros) y sus cinco interfaces, Lookup, Register, Admin, Link y Proxy- y las relaciones entre ellos que queremos modelar.

Figura 2: Metamodelo del trader

Modelo CIM: Trader​

La figura 3 muestra el modelo de operador CIM con sus cinco interfaces. También hemos utilizado GMF/Eclipse para desarrollar una herramienta de documentación de modelos de operador CIM. Utilizamos el lenguaje OCL para describir las restricciones semánticas de un operador. Algunos ejemplos de estas restricciones son:

• Si el trader implementa la interfaz Register, debe implementar también la interfaz Lookup.
• Si el operador implementa la interfaz Admin, también debe implementar la interfaz Register.
• Si el operador implementa la interfaz Link, también deberá implementar la interfaz Admin.
• Si el trader implementa la interfaz Proxy, también debe implementar la interfaz Admin.
• El valor del parámetro def_search_card debe estar comprendido entre 0 y 2147483647.
• etc...

Figura 3: Modelo del trader

Metamodelo PIM: diagrama de clases informal​

La figura 4 muestra un fragmento del metamodelo de diagrama de clases informal basado en UML. Este diagrama de clases es informal porque no representa todos los elementos del diagrama de clases UML. Sólo representa paquetes, clases, relaciones entre ellos, etc. El meta-modelo PSM (diagrama de clases formal) representa todos los conceptos del diagrama de clases UML.

Figura 4: Un fragmento del metamodelo de diagrama de clases informal

Modelo PIM: diagrama de clases informal del trader​

La figura 5 muestra el modelo de trader PIM: un diagrama de clases parcial. Podemos ver en esta figura cómo las cinco interfaces del trader implementan una interfaz funcional y estas interfaces funcionales extienden otras interfaces abstractas. También aparecen otras clases nuevas, como OfferRepository o LinkRepository.

Figura 5: Modelo de diagrama de clases informal del trader

Transformación de modelo a modelo​

Para traducir un modelo en vistas (etapas), utilizamos técnicas de transformación de metamodelos. En nuestro caso, utilizamos ATL (ATLAS Transformation Language) para implementar las transformaciones del trader. Este lenguaje proporciona construcciones declarativas e imperativas. La parte declarativa de ATL se basa en reglas. Dichas reglas consisten en un patrón de origen que se compara con los metamodelos de origen y en un patrón de destino que crea metamodelos de destino para cada comparación.

La figura 6 muestra un fragmento del código ATL para la transformación CIM/PIM de una de las cinco interfaces de un agente trader: la interfaz Lookup. La transformación de las demás interfaces es similar a ésta.

Figura 6: Un fragmento de la transformación de modelo a modelo ATL

Las siguientes secciones muestran gráficamente los elementos que se transforman del modelo de trader al modelo de diagrama de clases informal.

Transformación del trader​

La figura 7 muestra la transformación Trader. Podemos ver que el elemento Trader en el modelo trader se transforma en la clase Trader en el modelo de diagrama de clases informal. También se generan todos los paquetes, las interfaces abstractas de trader (TraderComponents, SupportAttributes, ImportAttributes y LinkAttributes), las clases necesarias (como OfferRepository o LinkRepository) y algunas relaciones.

Figura 7: Transformación del trader

Transformación de la interfaz Lookup​

La figura 8 muestra la transformación de la interfaz Lookup. Podemos ver que la interfaz Trader Lookup implementa la interfaz funcional Lookup, que además extiende las interfaces abstractas TraderComponents, SupportAttributes e ImportAttributes.

Figura 8: Transformación de la interfaz Lookup

Transformación de la interfaz Register​

La Figura 9 muestra la transformación de la interfaz Register. Podemos ver que la interfaz Trader Register implementa la interfaz funcional Register, que además extiende las interfaces abstractas TraderComponents y SupportAttributes.

Figura 9: Transformación de la interfaz Register

Transformación de la interfaz Admin​

La figura 10 muestra la transformación de la interfaz Admin. Podemos ver que la interfaz Admin del comerciante implementa la interfaz Admin funcional, que además extiende las interfaces abstractas TraderComponents, SupportAttributes, ImportAttributes y LinkAttributes.

Figura 10: Transformación de la interfaz Admin

Transformación de la interfaz Link​

La figura 11 muestra la transformación de la interfaz Link. Podemos ver que la interfaz Trader Link implementa la interfaz funcional Link, que además extiende las interfaces abstractas TraderComponents, SupportAttributes y LinkAttributes.

Figura 11: Transformación de la interfaz Link

Transformación de la interfaz Proxy​

La figura 12 muestra la transformación de la interfaz Proxy. Podemos ver que la interfaz Proxy del comerciante implementa la interfaz Proxy funcional, que además extiende las interfaces abstractas TraderComponents y SupportAttributes.

Figura 12: Transformación de la interfaz Proxy

Transformación de modelo a texto​

Al final, la generación de código Java a partir de modelos de comerciante PSM puede obtenerse a partir de un analizador sintáctico escrito en MOFScript.

La figura 13 muestra un breve fragmento del código MOFScript para la transformación de las clases del modelo de diagrama de clases formal del comerciante a clases Java.

Figura 13: Una parte de la transformación de modelo MOFScript a texto

Transformación de clases​

La Figura 14 muestra un ejemplo del código Java de las clases Trader y Lookup (Trader.java y Lookup.java, respectivamente) generado automáticamente.

Figura 14: Ejemplo generado