INGENIERIA WEB BASADA EN UML

Introducción

La metodología UWE, presentada por Koch y sus colegas, soporta el desarrollo de aplicaciones Web con especial énfasis en sistematización, personalización y generación de código semi-automático.

Se fundamentada en el análisis y diseño orientado a objetos, con procesos iterativos e incrementales definidas en el Proceso Unificado (UP). En su notación se utilizan perfiles ligeros de UML (UML profile), un perfil en UWE presenta estereotipos utilizados en el modelado de aspectos de navegación y presentación de las aplicaciones Web.

UWE proporciona guías para la construcción de modelos de forma sistemática enfocadas en el estudio de casos de uso. Las actividades del modelado son Análisis de Requerimientos, Diseño Conceptual, Diseño Navegacional y Diseño de Presentación producen los siguientes artefactos: 

• Modelo de Casos de Uso
• Modelo Conceptual
• Modelo de Espacio de Navegación y Modelo de Estructura de Navegación
• Modelo de Presentación.

El proceso UWE

Aplicando los principios de MDA, la metodología UWE propone construir un conjunto de CIM’s, PIM’s y PSM’s como el resultado de las fases de análisis, diseño e implementación del proceso. La fase de análisis apunta a obtener un conjunto de requerimientos estables. Los requerimientos funcionales son capturados a través del modelo de requerimientos. El modelo de requerimientos conforma casos de uso especializados y un modelo de clases para la aplicación Web. La fase de diseño consiste en construir una serie de modelos para el contenido, navegación, proceso, presentación y aspectos adaptativos a un nivel de plataforma independiente. Las transformaciones implementan la construcción sistemática de modelos dependientes por la generación de modelos por defecto, los cuales pueden ser refinados por el diseñador. Finalmente, los modelos de diseño son transformados a una implementación de plataforma específica PSM. Este proceso se extiende con la construcción de máquinas de estado UML (conocidos como la gran foto) que integran los modelos de diseño.

La siguiente figura ilustra la dependencia existente entre los correspondientes modelos de UWE:

Figura 1. Estructura de paquetes del metamodelo de UWE.

Utilizando un diagrama de actividades puede mostrarse los procesos que sigue UWE, en el mismo los modelos se representan con nodos de objetos y las transformaciones como actividades estereotipadas (círculos icónicos especiales), una cadena de transformaciones define el flujo de control.

Figura 2. Proceso UWE para transformaciones CIM2PIM y PIM2PIM.

Un ejemplo de modelos de Contenido, Navegación y Presentación en UWE sería el siguiente:

Figura 3. Ejemplos de Modelos de Contenido, Navegación y Presentación.

Metamodelo UWE

El metamodelo UWE está estructurado en paquetes para requerimientos, contenido, navegación, procesos y presentación de la aplicación Web. Están definidas como extensiones ligeras del metamodelo UML 2.0, proveyendo una descripción precisa de los conceptos usados para el modelado de aplicaciones Web y su semántica. A continuación describimos cada metamodelo.

1.    Metamodelo de Requerimientos

En UWE, se utilizan diagramas de casos de uso UML para definir los requerimientos funcionales de la aplicación Web y se usan diagramas de clase UML para representar el contenido de los requerimientos. 

La especificación de requerimientos involucra la construcción de:

• Un modelo de análisis de contenido que define la estructura de datos de la aplicación Web.
• Un modelo de casos de uso Web (WebUseCase) que define la funcionalidad de la aplicación.

La siguiente figura ilustra el metamodelo UWE para requerimientos:
 

Figura 4. Metamodelo para el Modelo de Requerimientos UWE.

Observando la figura se puede indicarlo siguiente:

• Se utilizan clases UML regulares para definir el contenido de la aplicación Web.
• Se utilizan las metaclases abstractas WebUseCase para representar la funcionalidad de la aplicación.
• El contexto para los casos de uso Web se representan por el atributo derivado contentClass. El contexto se refiere a la representación de la ubicación donde el usuario de la aplicación Web se sitúa actualmente.
• En cierto contexto el usuario puede ejecutar cierta funcionalidad contenida en el caso de uso Web.
• El cambio de contexto cuando se ejecuta el caso de uso Web se representa por el atributo derivado target.
• El atributo target corresponde a una asociación entre un WebUseCase y un contentClass.
• Se distinguen dos tipos de WebUseCase: Navigation y WebProcess.

El caso de uso Navigation representa la funcionalidad estática de navegación de la aplicación Web. Por estático entendemos que el contenido de los objetos no cambia cuando se ejecuta el caso de uso.
La funcionalidad dinámica de la aplicación Web se representa por el caso de uso WebProcess. La ejecución de WebProcess cambia el estado del sistema por la ejecución de diferentes acciones en el modelo de contenido. El caso de uso WebProcess representa el caso genérico de un proceso Web en un flujo de tareas. De WebProcess se especializan dos tipos, Edit y SimpleProcess. El caso de uso Edit permite modificar datos en la clase de contenido asociada. El caso de uso SimpleProcess representa la invocación a un método de la clase de contenido asociada. 

2.    Metamodelo de Contenido

El modelo de contenido para aplicaciones Web en UWE, utiliza modelos estándares UML para modelar estructuras de clases, asociaciones y paquetes.

Figura 5. Metamodelo para el Modelo de Contenido UWE.

De la figura podemos mencionar lo siguiente:

• ContentModel, representa el dominio de la aplicación Web.
• Un atributo de un elemento de dominio puede ser distinguido por una clave. La metaclase Key provee esta funcionalidad.

El modelo de contenido puede derivarse automáticamente del modelo de requerimientos aplicando la transformación Requirements2Content, el modelo de contenido resultante deberá ser refinado por el desarrollador adicionando clases, atributos, operaciones, asociaciones, etc.

3.    Metamodelo de Navegación

El objetivo del modelo de navegación es el de especificar las rutas de navegación del contenido de una aplicación Web. En este modelo los nodos representan la información del modelo de contenido y los enlaces (links) expresan las rutas de navegación entre los nodos.

En este modelo los nodos son representados por clases UML especializadas y los enlaces por asociaciones UML.

El modelo de navegación se construye de la siguiente forma:

1. Creación del modelo del espacio de navegación, el cual especifica los nodos que serán visitados por navegación directa a partir de otros.
2. Adición de estructuras de acceso al modelo de navegación.
3. Adición de menús al modelo para organizar los enlaces de salida de las clases de navegación.
4. Los elementos básicos del metamodelo de navegación son NavigationNode y Link, los cuales se derivan de los elementos UML Class y Association, respectivamente. El tronco de este metamodelo se ilustra en la siguiente figura.

Figura 6. Metamodelo para el modelado de navegación UWE. 

De la anterior figura se puede mencionar los siguientes:

• El modelo de navegación se construye en el modelo conceptual y representa la estructura de navegación de la aplicación Web entre diferentes entidades, el acceso a las entidades puede ser a través de query’s o menus.
• La clase NavigationNode es abstracta y puede ser de cualquier tipo en el grafo de navegación. Esto significa que si un nodo se alcanza durante la navegación, al usuario se le provee de cierta información y se le ofrece la posibilidad de manejar una o más acciones. Un NavigationNode no necesariamente representa una página en la aplicación Web, aunque sí debería hacerlo.
• La clase NavigationClass representa a un nodo navegable en la estructura de hipertexto y establece una conexión entre el modelo navegacional y el modelo de contenido. Una clase de navegación que se asocia con una clase del modelo de contenido está destinada a representar el contenido de una instancia de esa clase.
• La clase NavigationNode es abstracta, lo cual significa que solo clases especializadas del tipo NavigationClass pueden instanciar la misma. Si un nodo es designado como punto de entrada en la aplicación entonces se le deberá definir el atributo isHome. Si un nodo puede ser accedido desde cualquier lugar del modelo de navegación sin el uso de enlaces explícitos, entonces el atributo isLandmark debe ser definido.
• Los atributos de NavigationClass son instancias de la clase NavigationProperty. Esta clase permite definir el contenido de los elementos de IU. El valor de una propiedad de navegación se puede tomar directamente de la asociación a una propiedad de una clase de contenido o derivada de una expresión de selección.
• La clase Link es una clase abstracta, que solo puede ser instanciada por NavigationLink. Un Link conecta un nodo origen con uno destino el cual se expresa por una asociación entre Link y NavigationNode. Con el atributo isAutomatic un link será ejecutado automáticamente. También puede definirse una expresión de guarda que indica si el Link puede ser ejecutado.
• Menu es una clase de navegación especializada que es usada para estructurar los links de salida de una clase de navegación. Esta clase debe ser asociada a una clase de navegación.
• AccessPrimitive es usada para seleccionar una instancia de una clase de contenido que se transforma en el contenido de una clase de navegación.
• ExternalNode denota a un nodo que no pertenece a la estructura de la aplicación actual.
• Index permite seleccionar una instancia de clases de contenido de un conjunto de instancias compiladas durante la navegación previa. Esto significa que el usuario toma de un conjunto de instancias de clases de contenido del contexto de navegación previa, una instancia. Realizada la elección esta instancia se convierte en el objeto de contenido para la clase de navegación que sigue Index en la ruta de navegación.
• Query se usa para recuperar el contenido de una fuente de datos. A diferencia de Index, un Query no recupera un conjunto de instancias de clases de contenido de la ruta de navegación previa, pero si de una Base de Datos o cualquier otra clase de fuente de datos que soporten query’s.
• GuidedTour representa acceso secuencial a todos los elementos de una lista de instancias de NavigationClass. Esta lista generalmente es una lista ordenada.

Espacio de Navegación

El modelo de espacio de navegación indica que nodos pueden ser visitados por navegación directa a partir de otros nodos, aunque inicialmente no se especifica cómo se accederán dichos nodos, este refinamiento se lo realiza en sucesivos pasos adicionando elementos estructurales de acceso.
Este modelo involucra la definición de vistas de navegación de aquellas clases de contenido las cuales serán visitadas por navegación a través de la aplicación Web y por los links de navegación. Una vista de navegación de una clase de contenido contendrá solo un subconjunto de atributos de la clase o definirá atributos adicionales los cuales son derivados de la clase de contenido. 

4.    Metamodelo de Procesos

Los procesos proveen a una aplicación Web aspectos dinámicos. Un proceso está compuesto por uno o más subprocesos y/o acciones que el usuario ejecuta para alcanzar una meta. Una meta representará un cambio en el estado de la aplicación.

Existen diferentes notaciones UML propuestas para modelar procesos, entre las más conocidas están los diagramas de estados y diagramas de actividades. UWE utiliza diagramas de actividades las cuales proveen un mapa de las características funcionales del sistema por un lado y por otro representan el mapa de interacciones del usuario con el sistema.

El modelamiento de procesos en UWE utiliza un subconjunto de elementos UML aplicado a diagramas de actividades y extendiendo su notación para modelar elementos como excepciones, eventos o nodos de actividades estructurados.

El modelamiento de procesos en UWE está dividido en las siguientes partes:

• Integración de procesos, que permite integrar la ejecución de procesos desde el modelo de navegación.
• Procesamiento de datos, que permite representar el acceso a datos por los procesos.
• Flujos de procesos, representados en flujos de procesos dinámicos, que ejecutan operaciones desde el modelo de contenido.

Para las partes mencionadas, existen transformaciones automáticas que permiten derivar procesos de modelos anteriormente definidos.

Integración de procesos

La integración de procesos es una característica que permite actuar como una interface entre los procesos y la navegación. El metamodelo de integración está representada por dos elementos ProcessClass (clase de proceso) y ProcessLink (link de proceso).

Cada proceso está representado por una actividad de proceso (ProcessActivity) y una clase de proceso está asociada a su correspondiente caso de uso de proceso Web (Web Process Use Case). Para cada proceso se designa una clase de proceso integrado en el modelo de navegación. Los links de procesos son links especiales utilizados para invocar un proceso, en el link de proceso el origen o destino del mismo (pero no ambos) se debe ejecutar una clase de proceso.

Cuando se ejecuta un link de proceso que apunta a una clase de proceso se ejecuta la actividad de proceso correspondiente, los parámetros de entrada deben ser compatibles con la clase de contenido origen, los parámetros de salida de la actividad de proceso deben ser compatibles con la clase de contenido destino. El siguiente diagrama ilustra el metamodelo de integración de procesos:

Figura 7. Metamodelo de Integración de Procesos.

Flujo de Datos y de Procesos

El comportamiento del proceso Web se define por un modelo de flujo, además se requiere de un modelo de procesamiento de datos que define los datos necesarios para la ejecución del modelo de flujo. Los modelos de Procesos y de Datos  generalmente se elaboran concurrentemente.

Los diagramas UML de Actividades son usados para definir el modelo de Flujo. Una actividad en estos diagramas denotan un comportamiento parametrizado del proceso, el flujo de ejecución se representa por nodos de actividades conectados. Los nodos de control proveen estructuras de control para el procesamiento. Los nodos de objetos representan datos que fluyen a través de los nodos de actividades, un nodo de acción representa la ejecución de un proceso, pueden definirse acciones especiales para invocar otras actividades, como también acciones compuestas. El siguiente diagrama ilustra el metamodelo del modelo de datos de un proceso:

Figura 8. Metamodelo para el modelo de proceso de datos.

La clase UserAction es usada para modelar interacciones con el usuario en la aplicación Web, el efecto de esta acción es la de presentar la clase del proceso al usuario, solicitándole ingrese datos para dicha clase. El usuario ingresará los datos correspondientes a las propiedades de la clase del proceso y cuando haya terminado, estos datos estarán disponibles para la próxima actividad. Cabe mencionar que cada salida de la acción está representada por un pin que corresponde a una propiedad de la clase del proceso, si se define una clase de contenido para la clase de proceso entonces la acción de usuario debe tener un pin de entrada con un tipo que corresponda a un tipo de la clase de contenido. La siguientes figuras ilustran el metamodelo de flujo de datos:

Figura 9. Metamodelo para el Flujo de Procesos.

Figura 10. Nodos de Control UML.

Figura 11. Nodos de Objetos UML.

5.    Metamodelo de Presentación

El modelo de presentación define la apariencia que pueden tomar los modelos de navegación. Este modelo describe estructuras de objetos en base a clases especializadas que conforman las páginas Web. Las clases de presentación representan páginas Web que están compuestas de elementos de IU y otras clases de presentación. Por otro lado, también en estas clases pueden definirse varias propiedades físicas de apariencia que incluyen ordenamiento de los elementos del modelo y la definición de propiedades CSS (Cascading Style Sheets).

El metamodelo de presentación comprende la clase “Presentation” que es una clase especializada que representa una página Web o parte de una página Web en clases compuestas. Cada clase de presentación está asociada exactamente a un nodo en el modelo de navegación.

Los elementos de IU “User Interface Elements” son clases especializadas que representan los elementos de interface en una página Web. Se pueden distinguir diferentes tipos de elementos de interface como ser:

• Anchors, que representan enlaces “links” en una página Web, opcionalmente puede definirse una expresión de formato para especificar la etiqueta que el link va a tener.
• Output elements, que representan a elementos de salida o despliegue dinámico, comprende:
• TextElements, que son elementos de despliegue dinámico de datos de tipo texto.
• ImageElements, que son elementos de despliegue de imágenes accedidas a partir de URL’s.
• Input elements, que representan elementos de captura de datos en la página Web, comprende:
• TextInput, que son elementos de captura de datos a partir de cajas de texto.
• EnumerationInput, que son elementos de captura a partir de listas enumerativas de elementos.
• Selection, que son elementos de captura por selección.
• Static elements, que representan información estática en la página Web, comprende:
• StaticText, representan textos estáticos.
• StaticImage, representan imágenes estáticas

Por cada elemento de IU su apariencia física puede ser mejorada implementando los atributos cssClass y cssStyle.

La siguiente figura ilustra el metamodelo de presentación completo de UWE:

Figura 12. Metamodelo de Presentación UWE.

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.