OptimalJ como herramienta MDA David Huerta Lopo Rubén Zornoza Aguilar

OptimalJ como herramienta MDA Introducción a mda ¿QUÉ ES MDA? PROCESO DE DESARROLLO CON MDA. MODELOS EN MDA. OPTIMALJ COMO HERRAMIENTA MDA ¿QUÉ ES optimalJ? Características Tipo de herramienta case Arquitectura Caso práctico

Introducción a mda - ¿QUÉ ES MDA? - ¿Qué es en realidad Model Driven Architecture o MDA?. Se trata de un framework de desarrollo de software que define una nueva forma de construir software en la se que se usan modelos del sistema, a distintos niveles de abstracción, para guiar todo el proceso de desarrollo, desde el análisis y diseño hasta el mantenimiento del sistema y su integración con futuros sistemas. MDA pretende separar, por un lado, la especificación de las operaciones y datos de un sistemas, y por el otro, los detalles de la plataforma en la que el sistema será construido. Los principales objetivos de MDA son mejorar la productividad, la portabilidad, la interoperabilidad y la reutilización de los sistemas.

Introducción a mda - PROCESO DE DESARROLLO CON MDA - A grandes rasgos, el proceso de desarrollo del software con MDA se puede dividir en tres fases: Construcción de un Modelo Independiente de la Plataforma (Platform Independent Model o PIM), un modelo de alto nivel del sistema independiente de cualquier tecnología o plataforma. Transformación del modelo anterior a uno o varios Modelos Específicos de Plataforma (Platform Specific Model o PSM). Un PSM es un modelo de más bajo nivel que el PIM que describe el sistema de acuerdo con una tecnología de implementación determinada. Generación de código a partir de cada PSM. Debido a que cada PSM está muy ligado a una tecnología concreta, la transformación de cada PSM a código puede automatizarse.

Introducción a mda - PROCESO DE DESARROLLO CON MDA - El paso de PIM a PSM y de PSM a código no se realiza “a mano”, sino que se usan herramientas de transformación para automatizar estas tareas. A continuación se muestra de manera resumida el proceso de desarrollo con MDA, suponiendo que tenemos un único PSM:

Introducción a mda - MODELOS EN MDA - Un modelo es una descripción de todo o parte de un sistema escrito en un lenguaje bien definido. El hecho de que un modelo esté escrito en un lenguaje bien definido tiene una gran importancia en MDA, puesto que esto permite la interpretación automática por parte de transformadores o compiladores de modelos. UML es un lenguaje de modelado bien definido que se ha adoptado como el principal lenguaje de modelado en MDA. Pero MDA no está restringido a UML, sino que puede usar cualquier lenguaje bien definido. De entre los distintos tipos de modelos definidos en UML, los Modelos de Clases, que muestran la vista estática del sistema, son los más importantes dentro de MDA, ya que el PIM y la mayoría de PSMs son modelos de este tipo. Estos modelos se representan mediante Diagramas de Clases de UML.

Introducción a mda - MODELO INDEPENDIENTE DE PLATAFORMA (PIM) - Un Modelo Independiente de Plataforma o PIM es un modelo del sistema de alto nivel que representa la estructura, funcionalidad y restricciones del sistema sin incluir detalles específicos de una plataforma determinada. Este modelo servirá de base para todo el proceso de desarrollo, y es el único que debe ser creado íntegramente por el desarrollador. Como vemos, el PIM se modela mediante el diagrama de clases de UML.

Introducción a mda - MODELO específico DE PLATAFORMA (Psm) - Un Modelo Específico de Plataforma o PSM es un modelo del sistema con detalles específicos de la plataforma en la que será implementado. Se genera a partir del PIM, así que representa el mismo sistema pero a distinto nivel de abstracción. Podemos decir que el PSM es un PIM al que se le añaden detalles específicos para ser implementado en una plataforma determinada. El PSM es, pues, un modelo del sistema de más bajo nivel, mucho más cercano a la vista de código que el PIM. Puede incluir más o menos detalle, dependiendo de su propósito.

Introducción a mda - MODELO específico DE PLATAFORMA (Psm) - Para la construcción de PSMs se usan los perfiles UML (UML Profiles), que son extensiones de UML que permiten añadir información semántica a los modelos para expresar detalles específicos de la plataforma. Hay que destacar que a partir de un PIM pueden generarse varios PSMs, cada uno describiendo el sistema desde una perspectiva diferente. La transformación de PIM a PSMs puede llevarse a cabo de varias formas: Construyendo manualmente el PSM a partir del PIM. De forma semiautomática, generando un PSM esqueleto que es completado a mano. De forma totalmente automática, generando un PSM completo a partir del PIM. Para las transformaciones automáticas se utilizan herramientas especializadas. Estas herramientas tienen implementados distintos algoritmos de transformación para pasar de un tipo de modelo a otro, y suponen uno de los pilares de MDA.

OPTIMALJ OPTIMALJ COMO HERRAMIENTA MDA ¿QUÉ ES optimalJ? Características Tipo de herramienta case Arquitectura Caso práctico

¿QUÉ ES OPTIMALJ? Fue lanzada al mercado en 2.001 por Compuware Corporation y Sun Microsystems. Se trata de un entorno de desarrollo de aplicaciones empresariales que permite generar con rapidez aplicaciones J2EE completas directamente a partir de un modelo de alto nivel (PIM), utilizando patrones para codificar adecuadamente las especificaciones de J2EE y haciendo uso de los estándares del MDA. Elimina la complejidad que suponía hasta ahora el desarrollo de aplicaciones para plataformas J2EE, ya que permite al desarrollador interactuar con un modelo visual de la aplicación, generando automáticamente el código.

características ¿Cómo se comporta optimalJ frente a los siguientes propiedades? Soporte para PIMs: posee un fuerte soporte para especificar sistemas mediante PIMs. Soporte para PSMs: soporte medio para los tres tipos principales de PSMs (Base de datos, EJB y Web). Permite varias implementaciones: permite la generación de varios PSMs a partir del mismo PIM, pero todos van dirigidos hacia la misma plataforma (J2EE). Integración de Modelos: los distintos PSMs se integran perfectamente entre sí de forma transparente y automática, interaccionando sin problemas todas las campas entre. Interoperabilidad: permite exportar e importar modelos vía XMI (especificación para el intercambio de Diagramas) de manera sencilla.

características Acceso a la definición de las transformaciones: La versión OptimalJ Proffesional Edition no lo permite. Sin embargo, podemos tener acceso a los “patrones de transformación” con OptimalJ Architecture Edition. Verificador de modelos: La herramienta incluye buenos verificadores de modelos, tanto para el PIM como para cada uno de los PSMs. Expresividad de los modelos: Buena representación del PIM. Con respecto a los PSMs, especialmente para el modelo de presentación (Web), no posee la expresividad que cabría esperar. Uso de patrones: Con la herramienta OptimalJ Architecture Edition pueden definirse nuevos patrones y usarlos en nuestro proyecto. Soporte para la regeneración de modelos: La herramienta gestiona de manera excelente la regeneración de modelos, tanto a nivel de PSMs como de código.

características Transformaciones intra-modelo: En general, una vez construidos los PSMs, un cambio en un PSM no afecta al resto de PSMs. Trazabilidad: OptimalJ permite conocer para cualquier elemento del PSM su origen en el PIM y su destino en el código. Ciclo de vida: La herramienta engloba todas las fases del ciclo de desarrollo, a excepción de la fase de recogida de requisitos a la que no da soporte. Estandarización: OptimalJ usa los principales estándares relativos a MDA. Usa UML como lenguaje de modelado y puede importar/exportar modelos vía XMI. Almacena también todos sus modelos en un repositorio MOF. Control y refinamiento de las transformaciones: Aunque de manera muy limitada, permite refinar ciertos aspectos de las transformaciones.

características Calidad del código generado: El código generado por la herramienta está bien documentado e incorpora patrones de código. No obstante, esos mismos patrones de código empeoran la legibilidad del código y dificultan su modificación. Herramienta de soporte: A parte de modelos, OptimalJ incorpora un completo entorno IDE para editar los ficheros fuente. Incluye también un servidor de bases de datos (SolidDB), un servidor de EJB (JBoss) y otro de servlets/JSPs (Tomcat) para realizar las prueba.

Tipo de herramienta case En primer lugar, debemos de decir que no existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en una clase determinada. Podrían clasificarse atendiendo a: las plataformas que soportan, la fases del ciclo de vida de desarrollo del software que abarcan, la arquitectura de las aplicaciones que generan, su funcionalidad... En función de las fases del ciclo de vida que abarcan, se clasifican en: Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): apoyan todas las fases del ciclo de vida del desarrollo de software. Herramientas de alto nivel, U-CASE (Upper CASE, CASE superior): abarcan las primeras fases del desarrollo: análisis y diseño. Herramientas de bajo nivel, L-CASE (Lower CASE, CASE inferior): dirigidas a las últimas fases de desarrollo: construcción e implementación OptimalJ engloba casi todas las fases del ciclo de vida, abarcando análisis, diseño, codificación, depuración, prueba, despliegue y mantenimiento. No posee soporte para la fase de recogida de requisitos.  CASE integrado

Arquitectura Arquitectura OptimalJ: Modelo del Dominio (Domain Model) Modelo de Clases (Domain Class Model) Modelo de Servicios (Domain Service Model) Modelo de Aplicación (Application Model) Modelo de Presentación (Web) Modelo de Negocio (EJB) Modelo de Bases de Datos Modelo de Código (Code Model)

Arquitectura -Patrones- Asimismo, OptimalJ usa dos tipos de patrones: Patrones de transformación entre modelos: Patrones de tecnología (Technology patterns): transforma el modelo del dominio (PIM) en el modelo de aplicación (PSMs). Patrones de implementación (Implementation patterns): transforma el modelo de aplicación (PSMs) en código. Patrones funcionales para hacer transformaciones dentro de un modelo: Patrones de dominio (Domain patterns): patrones distribuidos por el usuario que permiten a los desarrolladores capturar, reutilizar y distribuir modelos del dominio. Patrones de aplicación (Application patterns): usan el mismo principio que los patrones del dominio, pero aplicados a los modelos de aplicación. Patrones de código (Codo patterns): patrones de bajo nivel aplicados al código.

Arquitectura - Modelo del dominio - Modelo Dominio (Domain Model): modelo de alto nivel mostrando arquitectura general del sistema, sin detalles de implementación. Equivale al PIM de la aplicación. Este modelo del dominio está formado a su vez por otros dos modelos: Modelo de Clases (Domain Class Model): en el modelo de clases se define la estructura de la información con la que trabaja la aplicación mediante un diagrama de clases UML. Este modelo es el PIM de la aplicación. Modelo de Servicios (Domain Service Model): el modelo de servicios permite definir vistas sobre las clases definidas en el modelo de clases. Dentro del modelo del dominio podemos definir Patrones de Dominio para reutilizar un modelo del dominio en futuros desarrollos.

Arquitectura - Modelo de aplicación - Modelo Aplicación (Application Model): modelo del sistema desde el punto de vista de una tecnología determinada (J2EE). Contiene los PSMs de la aplicación. El modelo de aplicación generado contiene tres tipos de modelos: Modelo de Presentación (Web): este modelo contiene la información necesaria para generar una capa Web para nuestra aplicación, según la plataforma J2EE. Modelo de Negocio (EJB): el modelo de Enterprise Java Bean (EJB) es una capa middleware encargada, entre otras cosas, de las transacciones, la seguridad, la persistencia y la escalabilidad de la aplicación. Modelo de Base de Datos: el modelo de base de datos de OptimalJ se usa para modelar todas las definiciones relevantes de la base de datos.

Arquitectura - Modelo de Código - Modelo Código (Code Model): código de la aplicación, generado a partir del modelo de aplicación, haciendo uso de los Patrones de Implementación. El código para la lógica de negocio (EJB), base de datos y presentación (Web) puede generarse automáticamente de forma separada, o todos a la vez. El código que genera OptimalJ es totalmente operativo y conforme a las especificaciones de J2EE. El código generado consiste en ficheros JAVA, JSPs y XML, beans de tipo entidad y de tipo sesión y código SQL. El código distingue entre bloques protegidos (coloreados en azul), que el desarrollador no puede modificar, y bloques libres (coloreados en blanco).

Arquitectura - esquema de los tipos de modelos y patrones - A continuación, se muestra un esquema de los tipos de modelos y patrones disponibles en OptimalJ:

CASO PRÁCTICO - concesionario -

CASO PRÁCTICO - ÍNDICE - VERSIÓN UTILIZADA (optimalj architecture edition 3.2) interfaz gráfica Creación de un proyecto Inspección de los paquetes de los modelos creados Creación de clases de dominio Creación de relaciones entre clases EDICIÓN DEL PROYECTO GENERACIÓN DEL MODELO DE APLICACIÓN GENERACIÓN DEL MODELO DE CÓDIGO COMPILACIÓN DEL PROYECTO CREACIÓN DE LAS TABLAS DE LA BASE DE DATOS PRUEBA DE LA APLICACIÓN OBTENIDA

Versión utilizada - OPTIMALJ architecture edition 3.2 - En Junio de 2.004 Compuware lanza OptimalJ 3.2, una nueva versión de su solución para el desarrollo de aplicaciones J2EE. OptimalJ 3.2 incorpora una nueva edición para desarrolladores, añadiéndose a las otras configuraciones: Profesional y Architecture. La licencia de la Architecture tiene un precio de 9.000 euros, la Profesional, de 4.500 euros y la Developer 710 euros, todos sin IVA. En cuanto a los requisitos tanto hardware como software, constituyen uno de los puntos flacos de OptimalJ. En la parte hardware, OptimalJ Architecture Edition, recomienda: 800 MB de espacio en disco, velocidad de la CPU de 1GHz, y recomendables 512 MB de memoria RAM. Y en la parte software, tener instalado el sistemas operativo Microsoft Windows 2000 ó XP, y la plataforma Java SDK 1.4.1 ó 1.4.2 (http://java.sun.com/j2se).

Caso práctico - interfaz gráfica -

CASO PRÁCTICO - creación de un proyecto - 1. En el menú seleccionamos Proyect > New OptimalJ Proyect… 2. En el campo Name, escribimos Concesionario y clicamos Next. 3. Seleccionamos el tipo de proyecto, New Model, y la dirección donde se guardará. Hacemos click en Next. 4. Seleccionamos la ruta donde estará el código, hacemos click en Next y Finish.

CASO PRÁCTICO - creación de un proyecto -

CASO PRÁCTICO - creación de un proyecto -

CASO PRÁCTICO - creación de un proyecto -

CASO PRÁCTICO - creación de un proyecto -

CASO PRÁCTICO - inspección de los paquetes de los modelo creados - 1. En la ventana Explorer [Domain Model], podemos expandadir concesionario.domain para ver los paquetes con el modelo de clases y el de servicios. 2. En la ventana Explorer [Application Model], podemos expandir concesionario.application para ver los paquetes con el modelo de aplicación.

CASO PRÁCTICO - creación de clases de dominio - 1. En el explorador Explorer [Domain Model], haciendo click con el botón derecho en el paquete domain.class seleccionamos New Child > DomainClass para iniciar el asistente Create DomainClass.

CASO PRÁCTICO - creación de clases de dominio - 2. En el campo nombre Name, escribimos cliente y hacemos click en Next.

CASO PRÁCTICO - creación de clases de dominio - 3. Añadimos los atributos a la clase clicando add.

CASO PRÁCTICO - creación de clases de dominio - 4. Por último, clicamos Finish para acabar la clase una vez que tenemos todos los atributos definidos con nombre y tipo. 5. En el Explorer [Domain Model], podemos hacer doble click en domain.class para ver la representación de la clase creada.

CASO PRÁCTICO - creación de clases de dominio - 6. Repetimos el proceso de creación de una clase de dominio para crear todas las clases necesarias de nuestro caso práctico.

CASO PRÁCTICO - creación de relaciones entre clases - 1. En el llamado Source Editor hacemos click con el botón de la barra de herramientas de la izquierda. 2. Pinchamos en una de las clases sobre las que queremos establecer la relación y sin dejar de hacer click arrastramos hacia la otra apareciéndonos así el asistente Create DomainAssociation.

CASO PRÁCTICO - creación de relaciones entre clases - 3. Para cada clase seleccionamos si la relación es de agregación y la cardinalidad correspondiente a dicha relación.

CASO PRÁCTICO - creación de relaciones entre clases - 4. Seleccionamos el nombre de la relación, Next y Finish.

CASO PRÁCTICO - creación de relaciones entre clases - 5. Hacemos todo el proceso para crear el resto de relaciones entre las clases de dominio.

CASO PRÁCTICO - edición del proyecto - Se puede hacer cualquier modificación en cualquier elemento de la clase haciendo click en el Explorer con el botón derecho del ratón en el elemento que queremos modificar y marcando Properties.

CASO PRÁCTICO - edición del proyecto - Creamos lo que serán las claves primarias: Podemos modificar cualquier cosa sobre el diagrama:

CASO PRÁCTICO - edición del proyecto - Creamos operaciones:

CASO PRÁCTICO - edición del proyecto - Creamos tipos enumerados:

CASO PRÁCTICO - edición del proyecto - Este es el resultado:

CASO PRÁCTICO - GENERACIÓN DEL MODELO DE APLICACIÓN - 1. En el menú, seleccionamos Model > Update All Models. 2. Seleccionamos concesionario, pinchamos Next y Finish.

CASO PRÁCTICO - GENERACIÓN DEL MODELO DE CÓDIGO - 1. En el menú, seleccionamos Model > Generate All> Code.

CASO PRÁCTICO - GENERACIÓN DEL MODELO DE CÓDIGO -

CASO PRÁCTICO - GENERACIÓN DEL MODELO DE CÓDIGO -

CASO PRÁCTICO - compilación del proyecto - 1. Elegimos Project > Compile Project. 2. Esperamos al mensaje Finished Project Concesionario en la Output Window.

CASO PRÁCTICO - creación de las tablas de la base de datos - 1. Iniciamos la BD Solid 2. En el Explorer [Code Model] abrimos \dbmsModuleCode. Hacemos click con el botón derecho en Solid_MetaDbms.sqm y seleccionamos SQL Workbench in context.

CASO PRÁCTICO - creación de las tablas de la base de datos - 4. Pulsamos Create para generar las tablas SQL, Exec Batch y salimos. 3. Pulsamos OK

CASO PRÁCTICO - prueba de la aplicación obtenida - Por ultimo ya podemos probar la aplicación obtenida en Test > Start Application Server.

¿Preguntas? ?