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

I Taller “Desarrollo de Software Dirigido por Modelos”

Málaga, 9, Noviembre, 2004

Jesús García, J. Rodríguez, Marcos MenarguezM.J. Ortín, J. Sánchez

Departamento de Informática y SistemasUniversidad de Murcia

http://dis.um.es/~jmolina

2

Contenidos

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

3

Objetivos

• Adquirir una comprensión de MDA.

• Conocer herramientas MDA más extendidas

• Identificar unas dimensiones para una comparación de herramientas MDA.

4

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

5

Desarrollo sin MDA

• Modelado de requisitos– Modelos Conceptual y de Casos de Uso

• Modelado de Análisis– Modelos de Clases y Colaboraciones

• Modelado del Diseño– Refinar modelos

• ImplementaciónPROCES

O

Casos de Uso

AltaUsuario

RealizarPedido

Autenticación

ModificaciónDatos

Usuario

Nombre: RealizarPedidoObjetivo: 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:

1. A: Inicia compra

2. S: Crea un carro de compras nuevo asociado a la sesión del usuario.

3. A: El Usuario selecciona y añade un producto al carro de compras.

4. S: El sistema genera un nuevo item en el carro de compras correspondiente al nuevo producto.

5. 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

Pedido

numeronifClientedireccionlocalidadprovincia

codigoPostaltipoTarjetaCredito

numeroTarjetaCreditocaducidadMescaducidadYear

tipoPagoLineaItems

totalestado

LineaItem

unidadestotal

1..n1 1..n1

Producto

nombrenumero

descripcionprecio

categoriaorigenFoto

1

1

1

1

ItemCarro

unidadestotal

11 11

Usuario

nombrenif

correousuarioclave

0..n1 0..n1

CarroCompras

precioTotalitems

tamaño

0..n1 0..n1

1

1

1

1

Eventos del usuario para “Realizar Pedido”

: Usuario : Sistema

cerrarPedido(nif,direcc,localidad,provincia,CP,tTarjeta,nºTarjeta,cMes,cAño,tPago)

añadirItem(codigo)

cambiarUnidades(codigo,unidades)

Colaboración “AñadirItem”

: Usuario

: CarroCompras

: ItemCarro

i : ItemCarro

: Producto

: MostrarProductos : Añadir

: CatalagoProductos

11: recalcularTotal()

1: añadirItem(codigo)

5: i:=getItemCarro(codigo)

10: [nuevoItem]put(codigo,i)

6: [!nuevoItem]incrementarUnidades()

9: [nuevoItem]i:=creaItem(p)7: [nuevoItem]p:=get(codigo)

2: añadirItem(codigo) 3: [primer producto] crear()


8: [nuevoItem]p:=buscar(codigo)

Arquitectura con JDBC y Struts

JDBCDAOFactory

JDBCItemDAOJDBCUsuarioDAO

JDBCPedidoDAO

JDBCLineaItemDAO

LineaItem DAO

PedidoDAO

UsuarioDAO

ItemDAO

HttpServlet

ActionForm

LoginForm ModificarCarroForm PedidoForm RegistroForm

AñadirCarroActionMostrarAnimalesAction EditarPedidoActionEditarRegistroAction SalvarPedidoActionLoginAction

SalvarRegistroAction ModificarCarroAction

Action

ActionServlet

IServicios

ServiceImpl FachadaCarroCompras

CarroCompras

precioTotalitems

tamaño

ItemCarro

unidadestotal

Producto

nombrenumero

descripcionprecio

categoriaorigenFoto

LineaItem

unidadestotal

Pedido

numeronifClientedireccionlocalidadprovincia

codigoPostaltipoTarjetaCredito

numeroTarjetaCreditocaducidadMescaducidadYear

tipoPagoLineaItems

totalestado

Usuario

nombrenif

correousuarioclave

DAOFactory

ExtendedActionServlet

10..n0..n 1111 1

11 11

1..n1 1..n10..n

1

0..n

1

Añadir Item (JDBC y Struts)

: Usuario

: CarroCompras

: ItemCarro

i : ItemCarro

: MostrarProductos

: ServiceImpl : ExtendedActionServlet aca : AñadirCarroAction

: FachadaCarroCompras

: Producto

: MostrarCarro

3: aca:=getAction()

Obtiene el ActionForward

Obtiene AñadirCarroAction

Hace uso del patrón DAO para recuperar el producto

Otiene un CarroComprasVO accedido desde JSP

14: recalcularTotal()

16: af:=findForward("sucess")


2: process()


4: af:=perform()17: mostrar()


15: ccVO:=listarCarroCompras()

9: i:=getItemCarro(codigo)

13: [nuevoItem]put(codigo,i)

10: [!nuevoItem]incrementarUnidades()

12: [nuevoItem]i:=creaItem(p)

11: [nuevoItem]p:=recuperarProducto(codigo)

7: [primer producto] crear()

8: añadirItemCarro(codigo)

13

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)

14

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 variasimplementaciones

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

15


P05 Interoperabilidad Opera con notaciones estándar y puede importar y exportar información a otras herramientas

P06 Definición detransformaciones

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.

16


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

17


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

18

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.

19

OptimalJ

PIM

PSM Relacional

Código SQL

PSM EJB

Código EJB

PSM Web

Código JSP/Servlets

20

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

21

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

22

ArcStyler

23

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

24

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”

25

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)

26

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

27

Estudio Comparativo

• Trazabilidad– 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

28

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

29

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.

30

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

31

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.

32

Conclusión Final

• 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?

33

Automatización

LenguajeMáquina

Lenguaje de Programación

Compilador

PIM

PSM

Código

Compilador

Compilador

Documents

Un estudio comparativo de dos herramientas MDA: OptimalJ y ArcStyler I Taller “Desarrollo de Software Dirigido por Modelos” Málaga, 9, Noviembre, 2004