Un estudio comparativo de dos herramientas MDA: OptimalJ y ArcStyler I Taller “Desarrollo de Software Dirigido por Modelos” Málaga, 9, Noviembre, 2004 Un estudio comparativo de dos herramientas MDA: OptimalJ y ArcStyler Jesús García, J. Rodríguez, Marcos Menarguez M.J. Ortín, J. Sánchez Departamento de Informática y Sistemas Universidad de Murcia http://dis.um.es/~jmolina

Contenidos Objetivos Desarrollo sin MDA La herramienta OptimalJ La herramienta ArcStyler Análisis comparativo Conclusiones

Objetivos Adquirir una comprensión de MDA. Conocer herramientas MDA más extendidas Identificar unas dimensiones para una comparación de herramientas MDA.

Método Caso de Estudio: Pet Store Herramientas: ArcStyler (io-Software) y OptimalJ (Compuware) Evaluación de OptimalJ (King’s College London y University of York) Identificar una lista de características a evaluar

Desarrollo sin MDA Modelado de requisitos Modelado de Análisis Modelos Conceptual y de Casos de Uso Modelado de Análisis Modelos de Clases y Colaboraciones Modelado del Diseño Refinar modelos Implementación PROCESO

Casos de Uso RealizarPedido Autenticación ModificaciónDatos Usuario AltaUsuario RealizarPedido

Nombre: RealizarPedido Objetivo: Realizar un pedido seleccionando y añadiendo productos a un carro de compras. Es posible cambiar el número de unidades de un producto del carro. Actores: Usuario Precondiciones: El usuario debe estar autenticado. Flujo Principal: A: Inicia compra S: Crea un carro de compras nuevo asociado a la sesión del usuario. A: El Usuario selecciona y añade un producto al carro de compras. S: El sistema genera un nuevo item en el carro de compras correspondiente al nuevo producto. S: Actualiza el importe total del carro de compras. Se repiten los pasos 3-5 varias veces 6. A: El Usuario finaliza la compra. 7. A: El Usuario introduce los datos personales del pedido: dirección, localidad, provincia, código postal. 8. A: El Usuario introduce los datos de la tarjeta de crédito: tipo de tarjeta, numero de tarjeta, mes y año de caducidad. 9. S: Genera pedido de compras con sus correspondientes líneas de pedido. Alternativas: 3.1. El producto se encuentra en el carro de compras. 3.1.1. S: El sistema incrementa en uno el número de unidades del producto del carro de compras. 3.2 El Usuario selecciona un producto del carro de compras e introduce el número de unidades del producto que desea. 3.2.1. S: Actualiza el carro de compras reflejando las nuevas unidades. Si el número de unidades era cero, elimina el producto del carro de compras. 9.1. La forma de pago es contra reembolso. En este caso, el usuario no tiene que introducir los datos de la tarjeta de crédito. 9.2. La forma de pago es mediante transferencia bancaria. En este caso, el usuario no tiene que introducir los datos de la tarjeta de crédito. Comentarios:

Modelo de Clases

Eventos del usuario para “Realizar Pedido”

Colaboración “AñadirItem”

Arquitectura con JDBC y Struts

Añadir Item (JDBC y Struts)

Herramientas MDA Dimensiones para un estudio comparativo Soporte de PIM y PSM Transformaciones Ajustables y parametrizadas Lenguajes de definición Plataformas soportadas Estándares MOF, UML, XMI, Repositorio, Profiles, QVT (futuro)

Características MDA (King College, 2003) Id Propiedad Descripción P01 Soporte para PIM Permite que se especifique un sistema mediante un modelo independiente de una plataforma concreta. P02 Soporte para PSM La herramienta captura una implementación de middleware de un sistema como un modelo que representa la arquitectura. P03 Permite varias implementaciones Posibilita la generación de varias implementaciones diferentes (varios PSM) a partir de la misma especificación del sistema (PIM) P04 Integración de Modelos Permite integrar diferentes modelos para producir una única aplicación

Características MDA (King College, 2003) P05 Interoperabilidad Opera con notaciones estándar y puede importar y exportar información a otras herramientas P06 Definición de transformaciones Proporciona un lenguaje de modelado para transformaciones y permite manipular las transformaciones P07 Soporte para manejar la complejidad de los modelos Proporciona mecanismos para manejar la complejidad de los modelos. P08 Verificación de modelos Permite comprobar la corrección de modelos P09 Expresividad de los modelos El lenguaje para representar PIM y PSM es lo suficientemente expresivo como para capturar de forma precisa la estructura y funcionalidad en los distintos niveles de abstracción.

Características MDA (King College, 2003) P10 Uso de Patrones Tiene técnicas para definir y aplicar patrones para la construcción de PIMs, PSMs y transformaciones. P11 Consistencia incremental Conserva los cambios realizados “manualmente” tras regenerar los modelos P12 Transformación de modelos Provee soporte para convertir un PSM en otros PSM, o un PIM a otros PIM P13 Trazabilidad Registro de transformaciones que permite conectar un elemento del PIM con los elementos del PSM en que se transforma o con el código que le corresponde. P14 Soporte del Ciclo de Vida En qué grado soporta el ciclo de vida del desarrollo de software

Características MDA (King College, 2003) P15 Uso de estándares Expresa sus modelos en UML, es capaz de importar y exportar modelos en XMI y de guardarlos en un almacén MOF P16 Control y refinamiento de las transformaciones Permite dirigir o controlar las transformaciones entre modelos, por ejemplo, entre PIM y PSM o entre PSM y código. P17 Calidad del código generado P18 Herramientas de soporte

OptimalJ Genera aplicaciones J2EE Versiones probadas OptimalJ Professional Edition 3.0 OptimalJ Architecture Edition 3.0 Uso de estándares MOF, UML, XMI Uso de patrones: inter e intra modelos Código organizado en bloques libres y protegidos Interfaz web generada es muy pobre, puede modificarse.

OptimalJ PIM PSM Relacional PSM EJB PSM Web Código SQL Código EJB JSP/Servlets

ArcStyler Versión utilizada 4.0.90 Usa estándares MOF, UML, XMI y JMI Arquitectura CARAT: cartuchos MDA Soporta marcas para anotar un PIM Los cartuchos definen las transformaciones Lenguaje JPython Cartuchos disponibles para .NET, J2EE, web services,.. Definición del conjunto de marcas para una plataforma Herencia de cartuchos

ArcStyler Framework Accesor para definir la capa presentación Un modelo Accessor define el flujo de control y datos de un modo abstracto. Cartucho WebAccessor genera JSP y servlet. Dos elementos en un modelo accesor: Controlador (Accessor) y Vistas (Representer). Soporta todo el ciclo de vida

ArcStyler

Estudio Comparativo Soporte PIM y PSM En OptimalJ un único PIM, en ArcStyler un PIM adicional para la capa de presentación (Accessor). ArcStyler proporciona marcas. En OptimalJ tres PSM explícitos, en ArcStyler depende de la transformación. En ArcStyler detalles de la plataforma en el PIM, si no hay un PSM Métodos de búsqueda distintos a la clave primaria

Estudio Comparativo Permitir varias implementaciones OptimalJ orientada a J2EE (ahora soporta más arquitecturas y TPL) ArcStyler soporta cualquier plataforma: Arquitectura CARAT Integración de modelos En OptimalJ, bridges entre modelos se generan automáticamente En ArcStyler es más complicado que los incorpore un cartucho, necesidad de código “pegamento”

Estudio Comparativo Acceso a las definiciones de transformaciones Posible en ArcStyler y OptimalJ (architecture edition) Lenguajes de transformación: TPL y Jython Verificación de modelos En ArcStyler depende del cartucho, OptimalJ: Verificador de PIM y Verificador de PSM Expresividad de los modelos Interfaz web: Modelo Accesor de Arcstyler frente al PSM de OptimalJ (ahora una herramienta similar)

Estudio Comparativo Consistencia Incremental Cambios en el código se mantienen al regenerar la aplicación: bloques libres y protegidos. En OptimalJ: algunos cambios en un PSM se trasladan a otros PSM y al PIM. Transformaciones entre modelos PIM-PSM, PSM-Código (OptimalJ) Depende de los cartuchos

Estudio Comparativo Trazabilidad Soporte del ciclo de vida Registro de transformaciones en OptimalJ pero no lo utiliza En ArcStyler no hay registro Soporte del ciclo de vida En OptimalJ no hay soporte para manejo de requisitos. ArcStyler soporta todo el ciclo de vida ArcStyler permite integrar todo tipo de herramienta

Estudio Comparativo Control de transformaciones Muy limitado en OptimalJ En ArcStyler las marcas dirigen las transformaciones Soporte del ciclo de vida En OptimalJ no hay soporte para manejo de requisitos. ArcStyler soporta todo el ciclo de vida ArcStyler permite integrar todo tipo de herramienta

Conclusiones ArcStyler y OptimalJ se ajustan bien a MDA Uso de estándares, Soporte de PIM y PSM, y Manejo de transformaciones OptimalJ orientado a J2EE y ArcStyler es abierto a cualquier plataforma. OptimalJ genera una aplicación sencilla con poco esfuerzo, pero con una interfaz muy pobre. ArcStyler dispone de un buen mecanismo para crear interfaces gráficas.

Conclusiones Decisiones de diseño importantes en una herramienta MDA Formas de anotar un PIM ¿Es necesario un PSM? Mecanismos para la manipulación de transformaciones ¿En que grado se permite ajustar las transformaciones? Naturaleza abierta o cerrada

Trabajo Futuro Estudiar otras herramientas y completar el estudio comparativo. Comparar lenguajes de transformación: Jython de ArcSyler con TPL de OptimalJ. Relación entre Accessor y casos de uso Entorno y proceso para el desarrollo de aplicaciones web.

Conclusión Final ¿El futuro es MDA? MDA todavía está en su infancia pero ya disponemos de herramientas con cierto grado de madurez: ArcStyler, OptimalJ. MDA potencia el modelado y revitaliza la generación de código ¿El futuro es MDA?

Lenguaje de Programación Automatización Lenguaje Máquina Código Compilador Compilador PSM Lenguaje de Programación Compilador PIM