INGENIERIA WEB GUIADA POR MODELOS

Ingeniería WEB

La World Wide Web y la Internet son posiblemente, los desarrollos más importantes en la historia de la computación. Estas tecnologías han llevado a todos (con cientos de millones más que eventualmente seguirán) a la era de la informática; además se han convertido en parte integral de la vida diaria en la primera década del siglo XXI.

Los sistemas y aplicaciones basados en Web (WebApps) ofrecen un complejo arreglo de contenido y funcionalidad a una amplia población de usuarios finales. La Ingeniería Web (IWeb) es el proceso con el que se crean WebApps de alta calidad. La IWeb no es un clon perfecto de la Ingeniería de Software, pero toma prestados muchos conceptos y principios fundamentales de ella. Además el proceso IWeb acentúa actividades técnicas y administrativas similares.

Esto conduce a una pregunta clave: ¿se pueden aplicar principios, conceptos y métodos de la ingeniería del software al desarrollo web? Es posible aprovechar muchos de ellos, pero su aplicación puede requerir un giro un tanto diferente.

Para evitar una Web enmarañada y lograr mayor éxito en el desarrollo y la aplicación de sistemas basados en Web complejos y a gran escala, existe una apremiante necesidad de enfoques disciplinados y nuevos métodos y herramientas con que desarrollar, desplegar y evaluar los sistemas y aplicaciones basados en Web. Tales enfoques y técnicas deben considerar las características especiales de los nuevos medios, los ambientes y escenarios operativos, y la multiplicidad de perfiles de usuario que colocan desafíos adicionales al desarrollo de aplicaciones basadas en Web.

La IWeb aplica “sólidos principios científicos, de ingeniería y de administración, y enfoques disciplinados y sistemáticos para el desarrollo, despliegue y mantenimiento exitosos de sistemas y aplicaciones basados en Web de alta calidad”.

Ingeniería WEB guiada por modelos

El Desarrollo del Software Guiado por Modelos (MDSD por sus siglas en inglés) está convirtiéndose en un enfoque ampliamente aceptado para el desarrollo aplicaciones complejas. MDSD se avoca al uso de modelos como la clave principal de artefactos en todas las fases del desarrollo, desde la especificación del sistema y análisis, hasta el diseño y la implementación. Cada modelo usualmente se enfoca en un problema, independiente del resto de los usos involucrados en la construcción del sistema. Además, la funcionalidad del sistema puede ser separada de su implementación final; la lógica de negocios puede separarse de la plataforma tecnológica planificada. Las transformaciones entre modelos permiten la implementación automática de un sistema desde diferentes modelos definidos para él.

El enfoque MDWE (Ingeniería Web Guiada por Modelos) provee metodologías y herramientas para el diseño y desarrollo de aplicaciones Web. Estas herramientas dirigen diferentes problemáticas usando modelos separados (navegación, presentación, datos, etc.), y son soportados por modelos compilados que producen la mayoría de las páginas y lógica de las aplicaciones Web basados en estos modelos. Sin embargo, estos propósitos también presentan algunas limitaciones, especialmente cuando tienen que modelar problemáticas futuras, tales como estilos arquitectónicos o de distribución. Más aún, los sistemas Web actuales necesitan interoperar con otras aplicaciones externas, algo que requiere su integración con servicios Web de terceros, portales y también con sistemas de legado (Legacy Systems). Finalmente, muchos de los propósitos de la IWeb no explotan completamente todo los beneficios potenciales de MDSD, tal como la completa independencia de la plataforma, transformación y mezcla de modelos, o metamodelado. Miller y Mukerji de la OMG han introducido un nuevo enfoque para organizar el diseño de una aplicación en modelos separados de tal forma que portabilidad, interoperabilidad y reusabilidad pueden obtenerse a través de la separación arquitectónica en problemáticas (concerns).

MDA cubre un amplio espectro de tópicos y usos (metamodelos basados en MOF, perfiles UML, transformación de modelos, lenguajes y herramientas de modelado, etc.) y también provee la interoperabilidad requerida entre modelos y herramientas de distintos proveedores de software. Otros campos de estudio, como la Factoría de Software provee conceptos y recursos efectivos para el diseño y desarrollo basado en modelos de aplicaciones complejas, y es una expectativa que también puedan ser utilizados en la IWeb.
 
La comunidad de Ingeniería Web esta consciente de esta tendencia y fueron emergiendo diferentes enfoques para proveer soporte al desarrollo de aplicaciones Web Guiada por Modelos. Estos enfoques introducen modelos conceptuales para describir diferentes aspectos que definen una aplicación Web de una manera abstracta. Se propone el uso de transformaciones modelo-a-modelo y modelo-a-texto para obtener código que represente sin ambigüedades el modelo conceptual de la aplicación Web. Varios métodos de la IWeb que siguen este enfoque son: OOHDM, WebML, WSDM, UWE y OOH. Todos estos métodos han sido aceptados ampliamente por la comunidad de Ingeniera Web y han sido probados y validados en varias aplicaciones. 

Propósitos de la Ingeniería WEB guiada por modelos

Como se mencionó anteriormente la IWeb es un dominio específico en el cual MDSD puede aplicarse, debido a sus características particulares: existe un conjunto de problemáticas que necesitan ser estudiadas (navegación, presentación, procesos de negocio, etc.); las clases básicas de aplicaciones Web son bien conocidas (centrado en el documento, transaccional, basado en flujo de tareas, colaborativo, etc.); y el uso de patrones arquitectónicos y características estructurales en sistemas Web son reducidos y bien definidos. De hecho, enfoques existentes de modelos basados en IWeb proveen excelentes metodologías y herramientas para el diseño y desarrollo de aplicaciones Web.
 

Estos enfoques vienen de dos grandes áreas. La primera, es una propuesta donde se usan métodos de diseño basados en hipermedios, introduciendo expresividad y mecanismos requeridos para capturar elementos relevantes de la Web, como la navegación. Ejemplos prominentes de estas iniciativas son HDM, WebML, W2000, WSDM. La mayoría están basadas en el modelo E/R, o en extensiones de este. Otro grupo más reciente de enfoques emergieron como extensiones de técnicas de desarrollo orientado a objetos, adaptándose a las características particulares de sistemas Web. En este grupo podemos encontrar métodos como OOHDM, UWE, OOWS, OO-H o MIDAS.

Estas propuestas son guiadas por modelos como contenido, navegación y presentación, luego por modelos compilados que producen la mayoría de las páginas y lógica de las aplicaciones Web desde los modelos originales. La mayoría cuentan con procesos de desarrollo que soportan su notación y herramientas particulares, y están siendo utilizadas en ambientes comerciales para la construcción de diferentes clases de sistemas Web. Y aunque todas las metodologías adoptan diferentes notaciones y proponen sus propias construcciones, todas comparten conceptos comunes, y de esta manera pueden ser consideradas como basadas en metamodelos comunes.

Identificación de modelos referenciales de aplicaciones WEB

En general, las clases de problemáticas involucradas en el desarrollo de aplicaciones Web dependerán directamente del tipo de aplicaciones Web que serán diseñadas y también de los requerimientos del proyecto. Las aplicaciones Web han sido clasificadas por su complejidad y su historia de desarrollo en:

1. Sitios Web centrados en Documentos, las cuales son colecciones jerárquicas de documentos HTML estáticas (básicamente, textos planos e imágenes) que ofrecen información de solo lectura basados en un conjunto de contenido estructurado, patrones de navegación y presentación de características diseñadas y almacenadas a priori. La simplicidad y estabilidad de estos sistemas limitan el ámbito del modelado Web en tres modelos: un modelo de interfaz de usuario estructurado que trata con el contenido de información solicitada por el cliente, un modelo de navegación que señala las rutas de la red entre la aplicación Web y el modelo de presentación que se refiere a los elementos visuales que están involucrados en las páginas Web.
2. Aplicaciones Web Transaccionales, los cuales incorporan soporte para persistir y almacenar datos, localización de información, control de concurrencia, tolerancia a fallas y administración de la configuración. Adicionalmente a los aspectos de navegación de cualquier aplicación de hipermedia, el desarrollo de aplicaciones Web transaccionales implica la necesidad de un modelo efectivo de estructura de información, el cual es capaz de capturar los procesos de inserción, actualización y eliminación de datos, y también de un modelo de distribución el cual permite el establecimiento de alternativas para el manejo de transacciones. Se requerirá una clara separación entre diseño de datos, aspectos de comportamiento de la aplicación y de interfaz de usuario.
3. Aplicaciones Web interactivas, las cuales son aplicaciones basadas en navegadores que proporcionan contenido dinámico de páginas Web, por esta razón proveen a los usuarios información personalizada. Esta característica requiere de un modelo de procesos que describa como las clases de negocio manejan la información almacenada (por ejemplo los elementos del modelo de estructura de información), y también requieren que los modelos de navegación y presentación sean parametrizables para proveer información a medida a los usuarios individuales de acuerdo a sus preferencias, metas y conocimiento. Más aún, este tipo de aplicaciones pone énfasis en el modelado no solo de estructura de información por sí misma y de sus futuros consumidores, pero también las relaciones o puentes entre el modelo de estructura de información, modelo de navegación y modelo del negocio.
4. Aplicaciones Web basadas en Workflow (flujos de trabajo), los cuales proveen soporte para el modelado de procesos de negocio, flujos de actividad, reglas de negocio, interacción entre actores, roles e infraestructura de alto-rendimiento para almacenamiento de datos (manejo de contenido). La información es necesaria no solo para los actores del sistema pero también para sus procesos. Para esta clase de aplicaciones Web, como mínimo se requieren los siguientes modelos: un modelo de estructura de interfaz de usuario, un modelo de navegación, un modelo de presentación, un modelo de estructura de información, un modelo de negocio (por ejemplo, la descripción de cómo la funcionalidad es encapsulada en componentes de negocio y servicios), un modelo de proceso (con una descripción de las características de los procesos internos) y un modelo de arquitectura de software identificando los subsistemas, componentes y conectores (software y hardware) que la aplicación debe tener.
5. Aplicaciones Web colaborativas, que son aquellas que se ejecutan por diferentes grupos de usuarios que acceden a los recursos Web para llevar a cabo una tarea específica. Estos están compuestos de modelos de descomposición de la aplicación Web diseñada en vistas o espacios de trabajo basados en diferentes roles de usuario. Para cada grupo de usuarios, los requerimientos funcionales, tareas y actividades que serán realizadas deben ser especificadas. Estos usos involucran modularidad y requerimientos de distribución en el modelo de proceso. Finalmente, la información valiosa que va a ser manipulada por vistas debe ser también modelada.
6. Aplicaciones Web orientadas a portales, los cuales integran recursos (datos, aplicaciones y servicios) de diferentes fuentes en un solo punto. Desde la perspectiva de usuario final, un portal es un sitio Web con páginas que son organizadas por alguna forma de navegación. Las páginas pueden desplegar contenido de HTML estático o servicios Web complejos. La personalización, que es el comportamiento que permite marcar la senda de los usuarios tanto como los flujos de mensajes en servicios Web colaborativos, son extremadamente relevantes en este tipo de aplicaciones. Por consiguiente, se necesita de un modelo  de coreografía para expresar el comportamiento esperado por procesos del sistema como por los servicios externos para poder chequear su compatibilidad e interoperabilidad que permitan componerlos para construir el portal.
7. Aplicaciones Web ubicuas, las cuales necesitan ser accedidas en cualquier momento y en cualquier lugar, y por cualquier medio, deben correr en una variedad de plataformas, incluyendo teléfonos móviles, asistentes digitales personales (PDA’s), computadoras desktop, etc. Esto implica que su presentación y modelos navegacionales deben ser adaptables no solo por diferentes clases de usuarios, pero también por diferentes clases de plataformas y contextos. Consecuentemente, esta clase de aplicaciones requiere modelar la separación entre plataformas-independientes y plataformas-específicas.

Separación de Problemáticas

La separación de problemáticas es una técnica general establecida en la ingeniería del software para reducir la complejidad de un sistema. También se aplica para el análisis y diseño de aplicaciones IWeb. Distinguiremos cuatro problemáticas en estas aplicaciones: contenido, navegación, proceso y presentación. En el nivel de análisis las problemáticas de contenido, navegación y proceso son capturadas juntas en el modelo de requerimientos el cual se basa en el uso especializado de casos de uso y clases regulares. A nivel de diseño todas las problemáticas son dirigidas separadamente. Cada problemática se representa por su correspondiente modelo, por ejemplo modelo de contenido, modelo de navegación, modelo de procesos y modelo de presentación.

Por otro lado la visión de MDA es la transformación automática de modelos de diseño de plataforma independiente a modelos de una plataforma Web específica, como ser plataformas Web J2EE o plataformas Web ASP.NET. La siguiente figura ilustra estas transformaciones:

               Fig 1. Transformaciones PIM2PSM.

Un argumento de MDA es que las tecnologías de hoy en día cambian rápidamente y para una nueva plataforma solo se requerirá de otra transformación que debe ser construida junto con el correspondiente metamodelo de la plataforma destino. Desafortunadamente, esta idea simple es relativamente poco práctica de implementar en aplicaciones reales. Sin embargo, los rápidos cambios de tecnología no ocurren a gran escala (como una plataforma Web totalmente nueva cada año), pero si en escalas más pequeñas evolucionando versiones de tecnología o por causas de arquitecturas modulares de plataformas Web, los cuales permiten enchufar diferentes tecnologías. Aunque, esto no es suficiente para considerar la plataforma destino como un todo. Habrá que tener en cuenta la descomposición de las partes de una plataforma y en la descomposición de sus correspondientes transformaciones.
 

Como resultado de esta discusión, la transformación de modelos PIM a modelos PSM deberá descomponerse en cuatro diferentes transformaciones para las problemáticas de contenido, navegación, proceso y presentación de una aplicación Web. Cada transformación parcial es el objetivo de una parte específica de la plataforma Web la cual es responsable de manejar la problemática correspondiente. Claro que, una parte de la plataforma puede manejar varias problemáticas. La plataforma Web deberá ser diseñada de tal forma que una parte pueda ser intercambiada sin la influencia de otras partes y sus correspondientes transformaciones, por ejemplo usar CORBA en vez de RMI como componente tecnológico en el modelo de contenido. Por consiguiente, en este enfoque la visión que tiene MDA de transformaciones a plataformas específicas es refinada de tal manera que las partes de una plataforma pueden ser intercambiadas separadamente.

               Fig 2. Descomposición de Transformaciones PIM2PSM.

Estado del Arte

En esta sección estudiaremos los métodos más relevantes de la IWeb que han sido propuestos para soportar el desarrollo de aplicaciones Web. En particular haremos análisis en el proceso que guía cada método, el enfoque que requieren para realizar las especificaciones de requerimientos de la aplicación Web y los mecanismos de generación de código propuestos por las mismas.

1.    OOHDM: Object Oriented Hypermedia Design Model
OOHDM fue desarrollado por Schwabe y Rossi en 1995. Fue uno de los primeros enfoques que provee una solución metodológica para el desarrollo de aplicaciones Web. Este enfoque toma algunas ideas propuestas en HDM HyperMedia Design Model y las aplica en un proceso de desarrollo bien definido basado en el paradigma Orientado a Objetos. OOHDM enfatiza en la separación de aspectos navegacionales de otros aspectos como son el aspecto conceptual y el aspecto de interface. Otros enfoques se han inspirado en esta idea de la separación de aspectos. Finalmente, es bueno remarcar que OOHDM no es un enfoque cerrado y está constantemente siendo extendido y actualizado.

El proceso de desarrollo en este enfoque está dividido en cinco fases principales:

• Captura de requerimientos: En esta fase, los usuarios que deben interactuar con la aplicación Web tienen que estar bien definidos. En versiones previas de OOHDM esta fase no era considerada, fue incluida después de hacerle algunas extensiones al método.
• Diseño Conceptual: Esta fase consiste en la definición de un esquema conceptual donde se describe el aspecto estático del sistema.
• Diseño Navegacional: En esta fase, definimos un diagrama de clases de navegación y un diagrama de estructura de navegación. El primero representa las posibles rutas de navegación estáticas en el sistema. El segundo extiende el diagrama de clases de navegación incluyendo accesos estructurados y contextos de navegación.
• Diseño de Interfaz Abstracta: Esta fase consiste en una descripción de la interfaz de usuario de una manera abstracta. Para hacer esto, se desarrolla un modelo de interfaz abstracta usando la técnica denominada ADV Abstract Data View.
• Implementación: En esta fase, la aplicación Web es implementada, y se basa en los modelos previos.

2.    W2000
W200 fue desarrollado por Luciano Baresi, Franca Garzotto y Paolo Paolini en 2001. Este método se presenta como una extensión  y adecuación de UML con conceptos de diseño Web que nació del modelo HDM.

El proceso de desarrollo de este método está dividido en 5 fases que son:

• Análisis de Requerimientos: Esta fase consiste en estudiar los requerimientos de la aplicación Web mediante casos de uso UML.
• Diseño de Evolución de Estado: En esta fase, el analista debe indicar cómo evolucionan los contenidos. Esta fase no es obligatoria, pero es requerida solo para aplicaciones con alta complejidad.
• Diseño de Hipermedia: Esta fase consiste en el diseño de la estructura navegacional de la aplicación Web. Esta fase se basa en el uso de HDM.
• Diseño Funcional: Esta fase especifica las operaciones principales que realizaran los usuarios en la aplicación.
• Diseño de Visibilidad: En esta fase, se definen perspectivas diferentes de la aplicación Web para cada tipo diferente de usuario.

3.    UWE: UML-Based Web Engineering
UWE fue desarrollado por Nora Koch desde 1998. UWE es un enfoque metodológico para el desarrollo de aplicaciones Web que se basa completamente en técnicas de diagramación con UML. Este enfoque está actualmente abierto y muchos investigadores están continuamente mejorándolo. UWE propone un proceso de diseño semi-automático soportado por herramientas CASE como ArgoUWE y MagricDraw.

El proceso de desarrollo de UWE está basado en MDA. De lo cual se genera un proceso MDD que sufre transformaciones de modelo automáticas en cada paso basado en reglas definidas a nivel de metamodelos. Podemos dividir este proceso en tres fases:

• Especificación de Requerimientos: estos requerimientos definen el modelo CIM.
• Elaboración de Modelos PIM: estos modelos se derivan de los modelos de requerimientos (frecuentemente con información adicional). En el nivel PIM, se diseñan modelos separados de las problemáticas de la aplicación Web (contenido, navegación, procesos de negocio y presentación). Estos modelos son integrados en una gran imagen que mezcla todas las problemáticas y se usa para validar el diseño de los modelos.
• Elaboración de Modelos PSM: los modelos PSM se derivan del modelo validado, desde el cual se puede generar código fuente.

4.    WebML: Web Modelling Language
WebML fue desarrollado por Piero Fraternalli y Stephano Ceri en el 2000. WebML es un lenguaje de modelación de alto nivel para aplicaciones Web. WebML sigue el estilo de los modelos Entidad-Relación y UML ofreciendo notación propietaria y representación gráfica usando sintaxis UML. Este enfoque actualmente no está cerrado y continuamente se extiende y mejora. WebML es uno de los pocos enfoques que presenta una herramienta que soporta todo el proceso de desarrollo denominada WebRatio. El proceso de desarrollo se divide en seis fases:

• Análisis de Requerimientos: esta fase se enfoca en la recolección de información acerca del dominio de la aplicación, las funciones esperadas y las específicas.
• Modelado Conceptual: esta fase consiste en definir esquemas conceptuales basados en WebML, los cuales expresan la organización de la aplicación a un nivel de abstracción alta e independiente de los detalles de implementación.
• Implementación: esta fase consiste en la traducción de esquemas conceptuales basados en WebML en una implementación tecnológica específica.
• Testeo y Evaluación: en esta fase, la aplicación Web es testeada y validada para poder mejorar sus cualidades internas y externas.
• Despliegue: esta fase consiste en desplegar una aplicación Web en el tope de la arquitectura específica.
• Mantenimiento y Evolución: en esta fase, la aplicación es mantenida y con posibles evoluciones después de su despliegue.

5.    WSDM: Web Site Design Method
WSDM fue desarrollado por De Troyer y Leune en 1998. Es un enfoque centrado en el usuario. WSDM define una aplicación Web describiendo los requerimientos de los diferentes grupos de usuarios que deben interactuar con ella. Fue uno de los primeros enfoques en considerar el problema de la diversidad de usuarios en aplicaciones Web. Su proceso de desarrollo se divide en cinco fases:

• Sentencias de Especificación de Misión: en esta fase, debemos expresar el propósito y el objetivo de la aplicación Web. Se deben declarar la audiencia destino.
• Modelado de Usuarios: en esta fase, los usuarios son clasificados y agrupados con el objetivo de estudiar los requerimientos del sistema de acuerdo a cada grupo de usuario.
• Diseño Conceptual: en esta fase, se diseñan diagramas de clase para representar el modelo estático del sistema y el modelo navegacional para representar las posibles navegaciones.
• Diseño de la Implementación: esta fase consisten en la traducción de los modelos definidos en la fase de diseño conceptual en un lenguaje abstracto que es interpretado fácilmente por la computadora.
• Implementación: en esta fase, el diseño de implementación resultante es escrito en un lenguaje de programación específico.

6.    OOWS
OOWS es una extensión de método de desarrollo de software orientado a objetos OO-Method para el desarrollo de aplicaciones Web, donde el modelo navegacional como el modelo de Contenido se representa por Diagrama de Clases. El aspecto de presentación es integrado en el aspecto de navegación, de tal forma que no existe un modelo dedicado a la presentación.

Recientemente, se propuso una extensión al modelo guiado por OOWS para soportar procesos de negocio con énfasis en la integración de aplicaciones externas y el desarrollo de interfaces de usuario dedicadas considerando tareas manuales y automáticas. Sin embargo, el modelo navegacional de OOWS ha sido extendido con la inclusión de elementos de interfaz de usuario gráficas para permitir la interacción entre usuarios y procesos de negocios usando la notación UML.

Los procesos son capturados en un modelo de proceso de negocio usando una versión extendida de BPMN (Business Process Modeling Notation) y su correspondiente metamodelo extendido para el modelado de negocio. Este provee conceptos como flujo de objetos (correspondiente a nodos de actividad o eventos), conexión entre objetos, líneas y artefactos (correspondiente a nodos de objetos). En el modelo del proceso se considera la ejecución de tareas manuales, por ejemplo, tareas que son ejecutadas por humanos y que no se ejecutan automáticamente por el sistema o por servicios Web.

7.    OO-H: Object-Oriented Hypermedia Method
El método OOH fue presentado por Jaime Gomez, Cristina Cachero y Oscar Pastor en el 2000. Este enfoque emerge formalmente como una extensión del método OO-Method. Sin embargo, en las más recientes publicaciones los autores disocian OOH de OO-Method y se enfocan en tratar de alcanzar la personalización de sitios Web. Este enfoque esta soportado por la herramienta Visual Wade.

El proceso de desarrollo se divide en cuatro fases:

• Análisis de requerimientos: en esta fase, los requerimientos de la aplicación Web son especificados para cada tipo de usuario.
• Ingeniería: esta fase involucra todas las actividades relacionadas al análisis y diseño del producto de software. En particular, estas actividades son cinco: dos actividades de análisis (análisis de dominio y navegacional) y tres actividades de diseño (diseño de dominio, navegación y presentación).
• Construcción y Adaptación: esta fase constituye la implementación de la aplicación Web.
• Evaluación por el Cliente: en esta fase, los clientes evalúan la aplicación Web desarrollada.

Conclusión de Métodos IWEB

Hemos presentado un análisis corto de los principales métodos que soportan el desarrollo de aplicaciones IWEB, en este análisis se describieron las fases de su proceso de desarrollo y su soporte por algunas herramientas de Software comerciales.

Como conclusión, podemos indicar que la metodología que se acerca más al enfoque MDA es indudablemente la metodología UWE, ya que es una extensión a UML y proporciona guías para la construcción de modelos MDA de forma sistemática y con pasos acertados.

Perfil UML para EJB

El presente artículo es una continuación de los artículos Transformaciones ATL con Perfiles UML y Adaptando BindingsEjb en Aplicaciones Oracle ADF, en los cuales se exponen y detallan los siguientes elementos: un metamodelo para clases Java, un perfil UML básico para EJB y un meta-framework denominado BindingsEjb para adaptar aplicaciones Oracle ADF utilizando la herramienta EJB 3.0.

Ahora estamos en la posición de plantear un metamodelo completo de clases Java así como también del perfil UML para EJB versión 3.0 que puede ser utilizado de manera productiva en un proyecto de desarrollo de software.

Metamodelo completo de clases Java

Las principales características que tiene este metamodelo se pueden resumir de la siguiente forma.

• Elementos genéricos de Java (JavaElements).
• Clases Java (JavaClass) que tienen asociados métodos (Methods) y atributos (Fields).
• Las clases Java pertenecen a un paquete (Package). 
• Modificadores Java (Modifiers) que indican si los elementos son públicos, estáticos o finales (public, static, final).
• Los métodos pueden contener un conjunto de parámetros (MethodParameter) de un tipo indicado.
• Existe un tipo de dato genérico (Type), el cual puede representar un dato primitivo de Java (por ejemplo String, Date, Integer, etc) o una clase Java, para los datos primitivos puede usarse el paquete donde esta implementado dicho dato (packageImpl).
• La clase Java (JavaClass) y la clase PrimitiveTypes son del tipo Type.
• En un paquete pueden definirse un conjunto de tipos Enumerativos Java (Enumeration) que poseen un grupo de literales (EnumerationLiteral).
• Un método tiene un cuerpo o código del metodo (body).
• Un atributo o campo de una clase, un parámetro de un método o el tipo de dato de retorno de un método, pueden definirse del tipo Type y según su cardinalidad (upperBound) puede definir una colección de datos (collectionType).
• Cualquier elemento de Java (JavaElement), puede tener asociado un conjunto de anotaciones (Annotations).
• Las anotaciones pueden definirse recursivamente (parentAnnotation) y utilizar un conjunto de atributos (AnnotationAtributte).
• Pueden definirse clases Java de tipo Generics utilizando JavaClassGeneric, en la misma se puede especificar si se usara Generics de Java (useGeneric) y también la clases genérica utilizando el atributo genericClass.
• Según las definiciones de clases genéricas en el modelo estas pueden utilizar en una clase Java, mediante el atributo superClasses.

La siguiente figura ilustra el metamodelo Java:

Fig 1. Metamodelo para clases Java

Para descargar el archivo ecore del metamodelo pueden presionar aquí.

Perfil UML para EJB 3.0

Para mejorar el uso del  perfil UML propuesto originalmente, se lo dividió en tres paquetes,  cada uno contiene un conjunto de estereotipos necesarios para la definición de elementos y anotaciones EJB, adicionalmente se crearon estereotipos para definir elementos utilizados en los patrones de diseño Data Transfer Object (DTO) y Data Access Object (DAO) utilizados en el meta-framework BindingsEjb. A continuación describimos brevemente los estereotipos elaborados en cada paquete.

Estereotipos del paquete EJB:

• EntityEJB, permite crear la anotación @EJB para una clase Java de tipo Entity Bean.
• StatelessEJB, permite crear la anotación @Stateless para una clase Java de tipo Stateless Session Bean.
• StatefulEJB, permite crear la anotación @Stateful para una clase Java de tipo Stateful Session Bean.
• MessageEJB, permite crear la anotación @Message para una clase Java de tipo Message Driven Bean.
• IdClassEJB, permite crear la anotación @IdClass a una clase Java de tipo Entity Bean.
• TableEJB, permite crear la anotación @Table a una clase Java de tipo Entity Bean.
• Remote Bussines Interface, permite crear la anotación @Remote a una Interface Java de tipo Remoto.
• Local Bussines Interface, permite crear la anotación @Local a una Interface Java de tipo Local.
• Message Listener Interface, permite crear la anotación @Message a una Interface Java para Mensajeria.
• PrimaryKeyField, permite crear la anotación @Id a un atributo de una clase Java de tipo Entity Bean que se considera como parte de la llave primaria.
• ColumnField, permite crear la anotación @Column a un atributo de una clase Java de tipo Entity Bean. Debe considerarse una serie de atributos (tag values) disponibles en el estereotipo que permiten definir la columna de forma completa.
• TransientField, permite crear la anotación @Transient a un atributo de una clase Java de tipo Entity Bean que se considere como de tipo Transient o no persistible.
• PersistenceContextField, permite crear la anotación @PersistentConext a un atributo de una clase Java que se considere pueda instanciar la clase EntityManager.
• GeneratedValueField, permite crear la anotación @GeneratedValue a un atributo de una clase Java de tipo Entity Bean que se considera como parte de la llave primaria y el Contenedor EJB genere el valor de la llave primaria para la clase.
• OneToOneRelation, permite crear la anotación @OneToOne a un atributo de una clase Java de tipo Entity Bean, este atributo se creara automáticamente por medio de una asociación entre dos clases Java con cardinalidad 1 – 1 (uno a uno).
• OneToManyRelation, permite crear la anotación @OneToMany a un atributo de una clase Java de tipo Entity Bean, este atributo se creara automáticamente por medio de una asociación entre dos clases Java con cardinalidad 1 – * (uno a muchos).
• PrePersistMethod, permite crear la anotación @PrePersist a un método de una clase Java de tipo Entity Bean que se considera como método callback a ejecutarse antes de persistir el Entity.
• PostPersistMethod, permite crear la anotación @PostPersist a un método de una clase Java de tipo Entity Bean que se considera como método callback a ejecutarse después de persistir el Entity.
• PreUpdateMethod, permite crear la anotación @PreUpdate a un método de una clase Java de tipo Entity Bean que se considera como método callback a ejecutarse antes de actualizar el Entity.
• PostUpdateMethod, permite crear la anotación @PostUpdate a un método de una clase Java de tipo Entity Bean que se considera como método callback a ejecutarse después de actualizar el Entity.
• PreDeleteMethod, permite crear la anotación @PreDelete a un método de una clase Java de tipo Entity Bean que se considera como método callback a ejecutarse antes de eliminar el Entity.
• PostDeleteMethod, permite crear la anotación @PostDelete a un método de una clase Java de tipo Entity Bean que se considera como método callback a ejecutarse después de eliminar el Entity.
• PostLoadMethod, permite crear la anotación @PostLoad a un método de una clase Java de tipo Entity Bean que se considera como método callback a ejecutarse después de recuperar el Entity.
• PostConstructMethod, permite crear la anotación @PostConstruct a un método de una clase Java de tipo Session Bean que se considera como método callback a ejecutarse después de construirse el Session Bean.
• PreDestroyMethod, permite crear la anotación @PreDestroy a un método de una clase Java de tipo Stateful Session Bean que se considera como método callback a ejecutarse antes de destruirse el Session Bean.
• PostActivateMethod, permite crear la anotación @PostActivate a un método de una clase Java de tipo Stateful Session Bean que se considera como método callback a ejecutarse despues de activarse el Session Bean.
• PrePassivateMethod, permite crear la anotación @PrePassivate a un método de una clase Java de tipo Stateful Session Bean que se considera como método callback a ejecutarse antes de inactivarse o colocarse en estado pasivo el Session Bean.

La siguiente figura ilustra el paquete EJB del perfil:

Fig 2. Estereotipos del Paquete EJB

Estereotipos del paquete DTO:

• DataTransferObject, utilizado para definir una clase Java como un DTO, en estos casos será necesario crear una relación de Dependencia entre la clase EntityBean y la clase Java para que el programa de transformación pueda crear los métodos necesarios para implementar este patrón de diseño tanto en el EntityBean como en la Clase DTO.
• CreateTransferObject y MergeTransferObject, estos estereotipos son solo referenciales por el momento no tiene una función específica en el proceso de transformación.

La siguiente figura ilustra el paquete DTO y sus estereotipos:

Fig 3. Estereotipos del Paquete DTO

Estereotipos del paquete DAO:

• DataAccessObject, utilizado para definir una clase Java como un DAO, en estos casos será necesario crear una relación de Dependencia entre la clase EntityBean y la clase Java para que el programa de transformación pueda crear los métodos necesarios para implementar este patrón de diseño en la Clase DAO. Adicionalmente, todas las clases DAO deberán generalizarse de clase GenericDAO que implementen bindeos de Templetas UML con el fin de implementar clases Java “Genericas”, esto según la definición de la clase GenericDAO del meta-framework BindingsEjb. Como referencia de Templetas UML revise el artículo “Defining Generics with UML Templates”.
• DeleteMethod, este estereotipo es solo referencial por el momento no tiene una función específica en el proceso de transformación.

La siguiente figura ilustra el paquete DAO y sus estereotipos:

Fig 4. Estereotipos del Paquete DAO

Para descargar el Perfil EJB completo puede hacerlo de aquí.
 

Transformación UML2Java

La transformación fue completamente modificada de la original (ver artículo Transformaciones ATL con Perfiles UML), la misma ahora soporta todos los estereotipos del Perfil EJB, algunas características que se añadieron son las siguientes:

Se añadieron métodos helpers que permiten realizar consultas a los elementos de UML así como variables auxiliares para apoyar  durante la transformación, como por ejemplo:

• Definir variables auxiliares para almacenar tipos de datos primitivos Java, tipos de Colección de Datos,  tipos de Persistencia EJB y Clases Java transformadas.
• helper def : primitiveTypesMap : Map(String,Java!PrimitiveType) = Map{};
• helper def : collectionsTypesMap : Map(String,Java!Type) = Map{};
• helper def : persistenceTypesMap : Map(String,Java!Type) = Map{};
• helper def : classMap : Map(String,Java!JavaClass) = Map{};
• Determinar tipos de asociación entre clases UML (relación entre una clase y otra)
• helper context UML!Association def: isBinary() : Boolean
• helper context UML!Property def: isSymmetric() : Boolean
• helper context UML!Property def: isInverseFunctional() : Boolean
• Convertir el método de una operación UML a string.
• helper context UML!Operation def: methodToString() : String
• Crear métodos para implementar el patrón de diseño DTO.
• helper context UML!Class def : createTransferObject() : String
• helper context UML!Class def : mergeTransferObject() : String

Se modificaron las reglas de emparejamiento con las siguientes funcionalidades adicionales:

• Todas las reglas de emparejamiento crean anotaciones Java, recorriendo todos los estereotipos definidos en el elemento transformado utilizando la regla createStereotype(e,g)
• La regla de emparejamiento que convierte un atributo UML (UML!Property)  a un campo Java (Java!Field), se divide en tres:
• A2F_PrivateAttribute, esta regla convierte solo atributos privados y si la cardinalidad del atributo es mayor a cero o menos uno (-1)  al campo Java se le asocia una colección de datos (List).
• A2F_ReadOnlyPublicAttribute, esta regla convierte atributos públicos de solo lectura a un campo Java privado, con un método getter y al igual que el anterior caso se le asocia una colección de datos si fuera necesaria.
• A2F_ReadWritePublicAttribute, esta regla convierte atributos públicos de lectura y escritura a un campo Java privado, con un método getter y un setter y además de asociar una colección de datos si fuera necesario.
• A2F_Association, esta regla convierte un atributo derivado de una asociación UML entre dos clases a un campo Java privado, adicionalmente se crean métodos getter y setter para dicho atributo y se asocia una colección de datos si fuera necesario.
• La regla de emparejamiento que permite convertir una operación UML (UML!Operation) a un método Java (Java!Method) es muy similar a la definida originalmente.
• Las reglas de emparejamiento para implementar los patrones de diseño DTO y DAO son las siguientes:
• Dependency2MethodDTO, esta regla convierte una dependencia UML (UML!Dependency) y que además tenga asociado la clase dependiente el estereotipo DataTransferObject  a los métodos getTransferObject, createTransferObject, setTransferObject y mergeTransferObject, además para cada método se define código Java por defecto.
• Dependency2MethodDAO, esta regla convierte una dependencia UML (UML!Dependency) y que además tenga asociado la clase dependiente el estereotipo DataAccessObject  a un método Constructor de la clase Java  además al método se añade código Java por defecto, también se crea un campo Java (Java!Field) que permita instanciar el objeto EntityManager de EJB, al mismo se asocian los métodos getEntityManager y setEntityManager.

Para descargar la transformación UML2Java.atl puede hacerlo de aquí.

Transformación Java2Code

La transformación original presentada en el artículo Transformaciones ATL con Perfiles UML, se modificó de la siguiente manera:

• Se añadió el método helper context Java!Type def : fullName() : String     que permite construir de manera completa el tipo de datos de un Java!Type donde se hace referencia al atributo packageImpl.
• Se modifica el método helper context Java!JavaElement def : fullType() : String  verificando la cardinalidad del elemento de Java (Java!Element) y si tiene asociado una colección de datos (atributos upperBound y collectionType), si es así al tipo de datos se le asigna la clase List.
• Se modifica el método helper context Java!JavaClass def : superClassesDef() : String   donde se verifica si la superclase asociada a la clase Java (Java!JavaClass) usa Generics (atributo useGeneric), si es así despliega la clase genérica entre los símbolos < y >.
• Se modifica el método helper context Java!Method def: toString() : String   para que imprima el código Java asociado si es que lo tuviese (atributo body). 

Para descargar la transformación Java2Code.atl puede hacerlo de aquí.

Modelo UML para transformación

Para aplicar las transformaciones anteriormente descritas, se elaboró el siguiente modelo UML en el cual se aplican los estereotipos del Perfil EJB:

Fig 5. Modelo UML para transformación.

Nótese que en las clases Persona, Usuario y Departamento, se aplicaron los estereotipos entityEJB, tableEJB y idClassEJB, para sus atributos los estereotipos primaryKeyField, columnField, en cada estereotipo se completaron sus propiedades (tagValues) apropiadamente. 

Fíjese que entre la clase Usuario y Persona se creó una asociación con cardinalidad Uno a Uno denominada Usuario_tiene_persona a la cual se le aplico el estereotipo OneToOneRelation, entre las clases Departamento y Persona se creó la asociación con cardinalidad Uno a Muchos denominada Lista_empleados, a esta se aplicó el estereotipo OneToManyRelation.

Observe que para relacionar un Entity Bean con una clase DTO y DAO se crearon dependencias entre las clases del modelo, por ejemplo el Entity Bean Persona tiene como clases dependientes PersonaDTO y PersonaDAO, cabe mencionar que PersonaDAO hereda la clase GenericDAO que a su vez hereda la clase GenericDAO, esta última clase es una implementación de una Templeta UML de tipo RedefinableTemplateSignature, la clase GenericDAO además de heredar de GenericDAO implementa un bindeo de Templeta  (Template Binding) donde el valor actual del parámetro (Template Parameter Substitution) se define de la clase Persona.

Finalmente se puede observar, que se crearon paquetes específicos para cada grupo de elementos comunes en el modelo, es decir por ejemplo el paquete bo.sigep.personal.entities agrupa a todas las entidades del modelo (Entity Beans).

Puede descargar el modelo “PersonasEJB.uml” de aquí.

Ejecución de las Transformaciones y serialización a código

La ejecución de las transformaciones tiene que ser en un orden específico es decir:

• Ejecutar UML2Java.atl, modelo de entrada PersonasEJB.uml modelo de salida PersonasEJB.xmi.
• Luego ejecutar Java2Code.atl, modelo de entrada PersonaEJB.xmi, como salida tendríamos el modelo serializado a código Java en la carpeta “src” del proyecto Eclipse, como ejemplo se muestran algunas clases.

Clase Persona.java

package bo.sigep.personal.entities;

@Entity
@Table(name = "PERSONAS", schema = "DBADMIN")
@IdClass(PersonaPK.class)
private class Persona {
 @Id
 @Column(name = "TIPO_ID")
 private java.lang.String tipoId;
 @Id
 @Column(name = "DOCUMENTO")
 private java.lang.String documento;
 @Id
 @Column(name = "EXPEDIDO")
 private java.lang.Integer expedido;
 @Column(name = "NOMBRES")
 private java.lang.String nombres;
 @Column(name = "APELLIDOS")
 private java.lang.String apellidos;
 @Column(name = "FECHA_NACIMIENTO")
 private java.util.Date fechaNacimiento;

 public java.lang.String getTipoId() {
  return this.tipoId;
 }

 public void setTipoId(java.lang.String tipoId) {
  this.tipoId = tipoId;
 }

 public java.lang.String getDocumento() {
  return this.documento;
 }

 public void setDocumento(java.lang.String documento) {
  this.documento = documento;
 }

 public java.lang.Integer getExpedido() {
  return this.expedido;
 }

 public void setExpedido(java.lang.Integer expedido) {
  this.expedido = expedido;
 }

 public java.lang.String getNombres() {
  return this.nombres;
 }

 public void setNombres(java.lang.String nombres) {
  this.nombres = nombres;
 }

 public java.lang.String getApellidos() {
  return this.apellidos;
 }

 public void setApellidos(java.lang.String apellidos) {
  this.apellidos = apellidos;
 }

 public java.util.Date getFechaNacimiento() {
  return this.fechaNacimiento;
 }

 public void setFechaNacimiento(java.util.Date fechaNacimiento) {
  this.fechaNacimiento = fechaNacimiento;
 }

 public bo.sigep.personal.dto.PersonaDTO getTransferObject() {
  return createTransferObject();
 }

 private bo.sigep.personal.dto.PersonaDTO createTransferObject() {
  PersonaDTO dto = new PersonaDTO();
  dto.setTipoId(this.tipoId);
  dto.setDocumento(this.documento);
  dto.setExpedido(this.expedido);
  dto.setNombres(this.nombres);
  dto.setApellidos(this.apellidos);
  dto.setFechaNacimiento(this.fechaNacimiento);
  return dto;
 }

 public void setTransferObject(bo.sigep.personal.dto.PersonaDTO dto) {
  mergeTransferObject(dto);
 }

 public void mergeTransferObject(bo.sigep.personal.dto.PersonaDTO dto) {
  this.setTipoId(dto.getTipoId());
  this.setDocumento(dto.getDocumento());
  this.setExpedido(dto.getExpedido());
  this.setNombres(dto.getNombres());
  this.setApellidos(dto.getApellidos());
  this.setFechaNacimiento(dto.getFechaNacimiento());

 }

}

PersonaDTO.java

package bo.sigep.personal.dto;

private class PersonaDTO {
 private java.lang.String tipoId;
 private java.lang.String documento;
 private java.lang.Integer expedido;
 private java.lang.String nombres;
 private java.lang.String apellidos;
 private java.util.Date fechaNacimiento;

 public java.lang.String getTipoId() {
  return this.tipoId;
 }

 public void setTipoId(java.lang.String tipoId) {
  this.tipoId = tipoId;
 }

 public java.lang.String getDocumento() {
  return this.documento;
 }

 public void setDocumento(java.lang.String documento) {
  this.documento = documento;
 }

 public java.lang.Integer getExpedido() {
  return this.expedido;
 }

 public void setExpedido(java.lang.Integer expedido) {
  this.expedido = expedido;
 }

 public java.lang.String getNombres() {
  return this.nombres;
 }

 public void setNombres(java.lang.String nombres) {
  this.nombres = nombres;
 }

 public java.lang.String getApellidos() {
  return this.apellidos;
 }

 public void setApellidos(java.lang.String apellidos) {
  this.apellidos = apellidos;
 }

 public java.util.Date getFechaNacimiento() {
  return this.fechaNacimiento;
 }

 public void setFechaNacimiento(java.util.Date fechaNacimiento) {
  this.fechaNacimiento = fechaNacimiento;
 }

}

PersonaDAO.java

package bo.sigep.personal.dao;

private class PersonaDAO extends
  org.mefp.core.ejb.dao.GenericDAO<bo.sigep.personal.entities.Persona> {
 private javax.persistence.EntityManager em;

 public void PersonaDAO() {
  super(bo.sigep.personal.dao.PersonaDAO.class);
 }

 public javax.persistence.EntityManager getEntityManager() {
  return this.em;
 }

 public void setEntityManager(javax.persistence.EntityManager em) {
  this.em = em;
 }

}

Conclusiones

Como se podrá observar el Perfil EJB creado tiene un grado de madurez aceptable, sin embargo le faltan definir algunos detalles como por ejemplo el uso de etiquetas @JoinColumn. 

En cuanto al metamodelo Java podríamos afirmar que es bueno, ahora contempla varias opciones que antes no tenía, como por ejemplo uso de Generics, uso de Colecciones de Datos, definición de código fuente, etc., pero no posee validaciones ni restricciones del modelo.

La transformación UML2Java.atl desde nuestro punto de vista está completa, le faltarían ejecutar pruebas de transformación de todo índole y con una variedad de casos mínimos y máximos, de esta manera detectar problemas con valores nulos (OclUndefined) que es el problema más frecuente.

La transformación Java2Code.atl, si bien contempla todos los casos y la generación de código es muy buena, habría que pensar en reemplazarla por un framework especializado en el manejo de templetas como XPand u otro.

El proceso de transformación y generación de código debería integrarse en un solo programa, que pueda ser ejecutado con un solo comando en el entorno Eclipse.

Todo lo presentado en el presente artículo es de manera experimental y con el afán de difusión, si existiesen nuevas ideas o propuestas, les adjunto el código para que puedan mejorar los programas de transformación elaborados.