Un enfoque de transformación de modelos para la composición automática de interfaces de usuario COTS en sistemas de información basados en web​

La globalización de la información y la Sociedad del Conocimiento requieren la modernización de los Sistemas de Información basados en Web (SIO) en interfaces de usuario evolutivas y adaptables. En la actualidad, las interfaces de usuario de los SIO se construyen siguiendo paradigmas de desarrollo tradicionales. Este artículo se inspira en una perspectiva de Desarrollo Dirigido por Modelos (MDD) para producir la composición automática en tiempo de ejecución de interfaces de usuario a partir de representaciones de modelos y metamodelos de arquitecturas de componentes de interfaz COTS de tipo widget y transformación de modelos.

Contenido​

1. Ejemplo de escenario
   1.1. Interfaz de usuario
   1.2. Diagrama de casos de uso
   1.3. Diagrama de interacción con el usuario
2. Transformación del modelo
   2.1. Metamodelo
   2.2. Modelo
   2.3. Transformación
3. Herramienta gráfica
   3.1. Etapas del proceso

Ejemplo de escenario​

Nuestra propuesta se inspira únicamente en los componentes widgets de una interfaz iGoogle. Debido a su naturaleza Web y a su simplicidad, estas interfaces (y componentes) son satisfactoriamente aplicables en entornos WIS. Sin embargo, no existen dependencias entre componentes y dichas dependencias no son adecuadas para ser utilizadas en entornos cooperativos SIO, donde diferentes grupos de personas y en diferentes lugares interactúan simultáneamente la interfaz para la toma de decisiones.

Interfaz de usuario​

Un SIO como SOLERES gestiona información medioambiental como mapas cartográficos e imágenes de satélite. Para describir cómo hemos utilizado la transformación de modelos en la metodología, supongamos una interfaz de usuario de un EMIS como la que se muestra en la siguiente figura:

La interfaz tiene una forma similar a la de iGoogle. Se compone de tres componentes de interfaz (tres cotsgets): un mapa cartográfico, un histograma relacionado con el mapa y un componente de Chat.

Diagrama de casos de uso​

En este escenario, se supone que dos usuarios del sistema acceden simultáneamente a la interfaz para realizar tareas de coordinación en la toma de decisiones. Por un lado, hay un usuario que desempeña el papel de Evaluador, que está realizando un estudio de evaluación de impacto ambiental y que puede necesitar el asesoramiento de un experto en SIG. La siguiente figura muestra el diagrama de casos de uso del entorno descrito:

Diagrama de interacción con el usuario​

La siguiente figura muestra un diagrama de secuencia, que explica la interacción de los usuarios con la interfaz y la interacción entre las clases que dependen de ella.

El proceso se inicia cuando ambos usuarios requieren coordinación a través de un "Chat". Ambos visualizan una interfaz compartida similar a la figura mostrada anteriormente. A través del componente "Chat", realizan operaciones de consulta y consenso y una vez finalizadas, el Evaluador cierra el "Chat" (paso #3). A continuación, se realiza internamente una petición al transformador para que actualice el modelo de arquitectura que ambos usuarios están visualizando en ese momento (arquitectura con tres componentes). Esta actualización del modelo se refiere a la interacción sobre un elemento de la interfaz, que debe reflejarse en el modelo. Una vez modificado el modelo para mostrar esta interacción, se ejecuta el transformador (#3.1.2), y el resultado es un nuevo modelo de interfaz (#3.1.3). A partir del nuevo modelo, el segundo paso consiste en regenerar la interfaz a partir de las restricciones impuestas en la arquitectura de la interfaz (el modelo). Este proceso es un servicio comercial que selecciona los componentes específicos que satisfacen las necesidades de dicha arquitectura. Debido a la simplicidad del ejemplo, este proceso genera los mismos componentes de la interfaz excepto "Chat", que ya no se imponía en la arquitectura (no estaba en el modelo). Dado que el artículo se centra en la transformación y no en la reconstrucción, hemos preferido presentar un ejemplo bastante sencillo para explicar el proceso de transformación del modelo.

Transformación del modelo​

La transformación de modelos es un marco general de la ingeniería de software en el que algunos modelos (visuales) se transforman en otros modelos. En UML (Lenguaje Unificado de Modelado), los modelos representan instancias de diagramas UML (diagramas de clases, máquinas de estados, diagramas de secuencia, etc.); dichas instancias pueden transformarse para tener diferentes vistas de un mismo modelo, o para obtener código en un lenguaje de programación concreto, entre otros ejemplos. La descripción de las transformaciones de modelos no sólo requiere lenguajes específicos para sus definiciones, sino también un meta-modelo para abstraer cualquier instancia del modelo.

Metamodelo​

Dado un enfoque MDD, definimos un perfil UML para representar arquitecturas de interfaz de usuario formadas por componentes cotsgets. El perfil se describió a través de un meta-modelo UML que se muestra en la siguiente figura:

El meta-modelo establece las reglas y elementos que describen la arquitectura de interfaz a través de un modelo (una instancia del meta-modelo). En este caso, la arquitectura de interfaz de los componentes cotsgets define diferentes aspectos no sólo de la interfaz en sí (es decir, aspectos visuales, posición, etc.) sino también dependencias entre componentes, interacción simple (individual) o compleja (cooperativa), entre otros aspectos. El presente trabajo se basa únicamente en las dependencias entre componentes. Así, consideraremos la arquitectura de interfaz como un conjunto de componentes con dependencias entre ellos.

Modelo​

Un componente de interfaz es un componente que ofrece un servicio y puede requerir el servicio de otros para funcionar. Por ejemplo, la siguiente figura muestra una arquitectura de interfaz de usuario para el escenario descrito en la Sección 1 y se corresponde visualmente con la interfaz de usuario mostrada. Las dependencias entre los tres componentes son desconocidas en la interfaz gráfica de usuario; sin embargo, en su modelo asociado (figura siguiente) el componente "Mapa" está ofreciendo un servicio al componente "Histograma", es decir, la parte de la interfaz que dibuja el histograma está asociada a un diagrama de entrada. Además, "Chat" está requiriendo cierta información de "Mapa" e "Histograma". Los componentes se definen mediante una clase UML vacía y estereotipada como "<>".

Las dependencias se representan mediante asociaciones UML (denominadas "conector"): con un nombre y dos roles. Los roles que empiezan por la etiqueta "out" representan una oferta de servicio (comportamiento del componente). El nombre del rol se crea añadiendo el nombre del componente asociado al rol y el nombre del componente que se está conectando. Por ejemplo, un conector "map_chat" puede vincular dos componentes cotsgets llamados "map" y "chat". El orden en el nombre indica la dirección de la dependencia. El origen se denomina rol de oferta "out_map_chat", y el destino "in_chat_map". En este último, el rol "in" significa que el componente requiere un servicio como entrada. Así, los roles "in" se representan como una flecha en el conector.

Transformación​

El proceso de transformación del modelo realiza un cambio en la interfaz de la arquitectura asociada (modelo B), partiendo de una situación inicial de interfaz de usuario establecida mediante cotsgets (modelo A) y una interacción del usuario con un elemento de un componente de interfaz de usuario. Como se ha avanzado anteriormente, el escenario de ejemplo parte de un modelo con tres componentes cotsgets. Cuando uno de los usuarios interactúa con un elemento cercano del componente Chat, el transformador cambia el modelo inicial a una arquitectura con dos componentes cotsgets. Por lo tanto, el proceso de transformación funciona sobre el metamodelo y los modelos de objetos, que son instancias de las interfaces de usuario del metamodelo. Las siguientes figuras muestran diagramas de objetos UML de modelos de objetos en la arquitectura de origen y de destino (modelos A y B). Dichos diagramas se almacenan en notación XMI (utilizada por el proceso de transformación de modelos).

A continuación, mostramos el código ATL que transforma la interfaz de origen proporcionada por el modelo A en otra B, una vez pulsado el botón "Cerrar". El metamodelo de entrada ("intMM") y el de salida ("outMM") son el mismo, definido como "meta_model.core" (líneas #1 a #5). El programa de transformación define una regla para cada elemento del metamodelo, es decir, una regla para los elementos "cotsget" (#7 a #11), otra para "attributes" (#13 a #17), otra para "in_port"(#19 a #25), "out_port" (#27 a #34) y "connector" (#36 a #44). La última regla (#46 a #50) copia el elemento raíz (modelo) en el nuevo modelo de destino añadiendo sus propiedades (cotsgets y conectores).

El transformador copia aquellos elementos del modelo de entrada que dependen de un componente cotsget que tenga un atributo "close" con valor "false".

Dichos elementos permanecen en el destino.Los que dependen de un componente cuyo atributo "close" tiene valor "true", no se copian en el modelo B. La regla "cotsget" (#7 a #11) cambia cada elemento de tipo cotsget ("inMM/cotsget") del metamodelo de entrada ("inMM") que tiene un atributo close falso ("attribute.close=false") en el mismo elemento del modelo de destino, copiando el valor de sus propiedades "name_cotsget" y "attributes" (es decir,"nombre_cotsget<-f.nombre_cotsget, atributos<-f.atributos"). La regla "Conector" (#36 a #44) cambia cada elemento conector del metamodelo in ("inMM"), cuyos puertos de entrada y salida pertenecen a un padre con su atributo "Close" establecido en "false" y ambos pertenecen a un componente diferente, en el mismo elemento copiando el valor de todos sus atributos (nombre, componente de origen y componente de destino). La restricción reflexiva mencionada anteriormente se comprueba para un conector. La transformación se produce si y sólo si el componente de origen y el componente de destino son diferentes.

Herramienta gráfica​

Una herramienta GMF de Eclipse permite dibujar (mapear) modelos de arquitecturas cotsgets (como se muestra en la Sección 2. El atributo name del conector se mapea como nombre de asociación y los atributos name de las clases "out_port" e "in_port" se mapean como nombres de rol en el modelo. El atributo name del conector se mapea como nombre de asociación y los atributos name de las clases "out_port" e "in_port" se mapean como nombres de rol en el modelo.Además, la flecha de la línea de asociación (dependencia) se coloca al final de la clase "in_port" del modelo de objetos.Veremos cómo aquellos atributos considerados como privados ("-") en el metamodelo aparecen en el modelo de objetos (el diagrama) y no en el modelo de arquitectura.

Etapas del proceso​

1. El primer paso consiste en definir un metamodelo en EMF. Este meta-modelo describe la arquitectura de nuestro prototipo de sistema. A partir de este meta-modelo, podemos definir modelos de interfaz de usuario construidos en base a componentes (cotsget). En estos modelos, también representamos las dependencias detrás de los componentes del sistema.

2. Eclipse Modeling framework nos permite desarrollar una herramienta gráfica a partir del meta-modelo; Graphical Modeling Framework (GMF) en concreto. Utilizamos esta herramienta para construir modelos de componentes de la arquitectura.

3. Por ejemplo, definimos un modelo inicial con tres componentes (Mapa, Histograma y Chat) y sus dependencias.

4. El siguiente paso es modificar el modelo construido. Para ello, debemos cambiar el nombre del modelo de la extensión .meta_model a .xmi. A continuación, podemos cambiar el valor de los atributos del modelo a través del "Sample Reflective Ecore Editor" de Eclipse Modeling Framework. En nuestro caso, estos cambios simularán eventos de usuario. Para este ejemplo, simulamos el evento de cierre del componente chat y cambiamos a "true" el valor del atributo "close" del componente chat.

5. Defina una transformación M2M (Modelo-a-Modelo). Tanto el modelo de entrada como el modelo de salida tienen el mismo meta-modelo de referencia. Esta transformación se desarrolla en ATL y sus reglas pretenden copiar los componentes del modelo de entrada al modelo de salida, excepto aquellos componentes que tengan un valor del atributo "close" a "true", aquellos puertos contenidos en componentes de cierre o conectados con componentes van a ser cerrados, y los conectores que enlazan puertos de componentes van a ser cerrados. Las reglas definidas son las mismas que mostramos en la Sección 2 - Transformación:

6. Ejecutando la transformación, obtenemos el siguiente modelo de salida con extensión XMI. Podemos ver como se ha eliminado un componente así como sus puertos y conectores relacionados del modelo:

7. Renombramos el modelo de salida de la transformación de .xmi a .meta_model (o el nombre de extensión del plugin que hayamos decidido). A continuación, hacemos clic con el botón derecho y seleccionamos "Initializate meta_model_diagram diagram file..." y obtenemos el diagrama del nuevo modelo.