Post on 02-Feb-2016
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()
4: añadirItem(codigo)
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")
1: añadirItem(codigo)
2: process()
6: añadirItem(codigo)
4: af:=perform()17: mostrar()
5: añadirItem(codigo)
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
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 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
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
17
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
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