vivagui: visualización y manejo de variabilidad en modelos

UNIVERSIDAD DE LOS ANDESFACULTAD DE INGENIERÍA

Departamento de Sistemas y ComputaciónGrupo de construcción de software

ViVaGUI: Visualización y manejode variabilidad en modelos de interfaces Web

Sandra Liliana Madrigal Fierro

Trabajo de grado presentado para optarpor el título de Magíster en Ingeniería de Sistemas y Computación

en la Universidad de los Andes

Julio, 2012

Asesor: Dr. Rubby CasallasJurados: Dr. Carlos Parra

Dr. Oscar Gonzalez

Resumen

El Desarrollo Dirigido por Modelos (Model Driven Development - MDD)[1] pro-pone manejar un nivel de abstracción adicional para el desarrollo de software,mediante la representación del problema y la solución por medio de modelos,este nivel de abstracción permite centrar el esfuerzo en la representación de lasolución y reduce la complejidad del desarrollo porque se deja esta preocupacióna lo de�nido en este enfoque, el MDD ofrece mecanismos que permiten lograrla independencia de las aplicaciones a las plataformas de desarrollo y responderla demanda del mercado de contar con aplicaciones en periodos muy cortos detiempo y con presupuesto más reducidos.

La Ingenería web Dirigida por Modelos (Model Driven web Engineering)[2][3]es un enfoque que integra las características del Desarrollo de Software Dirigidopor Modelos con los procesos del desarrollo web, con el �n de manejar la hetero-geneidad y evolución continua de las plataformas de este dominio y lograr centrarel esfuerzo en la independencia del contenido, la navegación, la presentación yla arquitectura que describen la aplicación, separando estas preocupaciones yobteniendo ventajas en términos de calidad, usabilidad, reutilización y manteni-bilidad.

Existen iniciativas de desarrollo de software basado en modelos para la creaciónde aplicaciones web, cuya principal �nalidad es aumentar la productividad en lacreación de software mediante la generación de parte del código fuente de maneraautomática.

Estos proyectos basados en modelos usualmente son manipulados por mediode dos tipos de representación, la primera consiste en una estructura de árboly la segunda en una sintaxis textual, sin embargo, para la de�nición de mod-elos de formularios de interfaz grá�ca estas alternativas no son su�cientes paraobtener una representación visual de los formularios de�nidos, para obtener estavisualización, es necesario realizar actividades como la generación automáticadel código, con�guración, compilación y despliegue de la aplicación auto gener-ada, con el �n de obtener un primer acercamiento del formulario de�nido, adi-cionalmente si se evidencia la necesidad de realizar ajustes sobre los formulariosobtenidos, es necesario realizarlos de manera manual, proceso dispendioso parael desarrollador.

Para suplir esta necesidad, esta tesis presenta una propuesta para la extensiónde las iniciativas web basadas en modelos, mediante la integración de un editorgrá�co independiente a la plataforma que permita mostrar una representaciónvisual de los modelos de formularios de interfaz grá�ca y la posibilidad de realizarajustes y con�guraciones sobre cada componente del formulario de manera grá�cae interactiva, logrando visualizar y con�gurar el formulario antes de los procesosde generación y despliegue de la aplicación, certi�cando al desarrollador queobtendrá el formulario previamente visualizado y reducirá de manera signi�cativalos ajustes a realizar sobre el mismo.

i

Agradecimientos

Agradezco el apoyo ofrecido por mi asesora Rubby Casallas por aportarme su ex-periencia para la de�nición de esta investigación y guiarme en todo el proceso dedesarrollo de la misma. Sus aportes siempre fueron de gran apoyo para culminaresta etapa y su comprensión el mayor don ofrecido.

Al Grupo de Construcción de Software de la Universidad de los Andes agradezcosus aportes valiosos para este trabajo.

Quiero agradecer a Jaime Chavarriaga por haberme aportado su experiencia enel campo del desarrollo dirigido por modelos y por siempre tener la disposiciónde enseñar y aportar a esta tesis.

Agradezco a mis jurados Carlos Parra y Oscar Gonzalez por tomarse el tiempoy la dedicación para leer esta tesis y hacer parte de este proceso de culminación.

Gracias también a mis queridos compañeros, que me apoyaron y me permitieronentrar en su vida durante estos tres años de convivir dentro y fuera del salón declase.

Finalmente, gracias a mi familia y a mi novio que me acompañaron de formaincondicional en esta etapa y entendieron mis ausencias y preocupaciones.

ii

Table of Contents

Resumen i

Agradecimientos ii

Tabla de Contenidos iii

Lista de Figuras v

Lista de Tablas vii

1 Introducción 1

1.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Descripción del Problema . . . . . . . . . . . . . . . . . . . . . . 21.3 Estrategia de Solución . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Contribución de la Tesis . . . . . . . . . . . . . . . . . . . . . . . 31.5 Validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6 Organización del Documento . . . . . . . . . . . . . . . . . . . . 5

2 Contexto 7

2.1 Desarrollo de Software Basado en Modelos (MDD por sus siglasen inglés) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Ingeniería web Basada en Modelos (MDWE) . . . . . . . . . . . . 92.3 Variabilidad Fina y Variabilidad Gruesa . . . . . . . . . . . . . . 102.4 Representaciones de Modelos y Editores Grá�cos . . . . . . . . . 10

3 Estado del Arte 13

3.1 UWE (UML-based web Engineering) . . . . . . . . . . . . . . . . 133.2 UCEd (Use Case Editor) . . . . . . . . . . . . . . . . . . . . . . . 143.3 MD-WEB-SPL (Líneas de Producto de Software para Aplicaciones

web Dirigida por Modelos) . . . . . . . . . . . . . . . . . . . . . . 153.4 GENIUS (Aproximación para la generación de interfaces web de

aplicaciones empresariales basadas en patrones de casos de uso) . 153.5 Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Estrategia de Solución 19

4.1 GENIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Alternativas de Solución . . . . . . . . . . . . . . . . . . . . . . . 224.3 Alternativa Seleccionada . . . . . . . . . . . . . . . . . . . . . . . 24

5 ViVaGUI 27

5.1 Visión General . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Visualizar el Modelo de Formularios Grá�cos . . . . . . . . . . . 28

iii

iv Table of Contents

5.2.1 Metamodelo de Formularios (FORMS) . . . . . . . . . . . 285.2.2 Metamodelo del Editor Grá�co XWT . . . . . . . . . . . 315.2.3 Transformación de Modelo a Modelo (Forms2XWT) . . . 325.2.4 Transformación de Modelo a Texto (XWT2Text) . . . . . 325.2.5 Herramienta de Visualización . . . . . . . . . . . . . . . . 33

5.3 Con�gurar la Variabilidad por Componente Grá�co . . . . . . . . 345.3.1 Creación del Modelo de Características . . . . . . . . . . . 355.3.2 Creación del Modelo de Restricciones . . . . . . . . . . . . 365.3.3 Plugin de Eclipse para Con�gurar la Variabilidad . . . . . 37

5.4 Con�gurar los Estilos sobre los Formularios . . . . . . . . . . . . 385.4.1 Con�guración de los Estilos sobre los Formularios . . . . . 38

6 Validación 41

6.1 Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.1.1 Visualizar el Modelo de Formularios . . . . . . . . . . . . 436.1.2 Con�guración de la Variabilidad por Componente Grá�co 446.1.3 Con�guración de los Estilos Sobre los Formularios . . . . 45

6.2 Métricas de Validación . . . . . . . . . . . . . . . . . . . . . . . . 45

7 Conclusiones y Trabajo Futuro 49

7.1 Contribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497.2 Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Bibliografía 51

List of Figures

2.1 Arquitectura MOF . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Elementos de las transformaciones . . . . . . . . . . . . . . . . . 92.3 Representación estructura de árbol . . . . . . . . . . . . . . . . . 102.4 Representación sintaxis textual . . . . . . . . . . . . . . . . . . . 11

4.1 Proceso GENIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Proceso ViVaGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1 Proceso ViVaGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2 Metamodelo Forms . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 Metamodelo Forms Paquete Core . . . . . . . . . . . . . . . . . . 295.4 Metamodelo Forms Paquete FormElements . . . . . . . . . . . . 295.5 Metamodelo Forms Paquete Model . . . . . . . . . . . . . . . . . 305.6 Metamodelo Forms Paquete Event . . . . . . . . . . . . . . . . . 305.7 Metamodelo Forms Paquete Internationalization . . . . . . . . . 305.8 Metamodelo XWT . . . . . . . . . . . . . . . . . . . . . . . . . . 315.9 Metamodelo XWT . . . . . . . . . . . . . . . . . . . . . . . . . . 315.10 Transformación Forms2XWT . . . . . . . . . . . . . . . . . . . . 325.11 Tranformación XWT2Text . . . . . . . . . . . . . . . . . . . . . . 335.12 Ejecución de la visualización del modelo de formularios . . . . . . 345.13 Visualización del modelo de formularios . . . . . . . . . . . . . . 345.14 Creación del modelo de características . . . . . . . . . . . . . . . 355.15 Modelo de características . . . . . . . . . . . . . . . . . . . . . . 355.16 Creación del modelo de restricciones . . . . . . . . . . . . . . . . 365.17 Modelo de restricciones . . . . . . . . . . . . . . . . . . . . . . . . 375.18 Con�gurar la variabilidad . . . . . . . . . . . . . . . . . . . . . . 375.19 Resultado de la variabilidad . . . . . . . . . . . . . . . . . . . . . 385.20 Resultado de la variabilidad . . . . . . . . . . . . . . . . . . . . . 38

6.1 Modelo de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . 426.2 Modelo de formularios . . . . . . . . . . . . . . . . . . . . . . . . 426.3 Visualización del formulario Asociación Curso a Estudiante . . . 436.4 Con�guración de Variabilidad . . . . . . . . . . . . . . . . . . . . 446.5 Con�guración de Estilos . . . . . . . . . . . . . . . . . . . . . . . 456.6 Resultado validación modelos complejidad alta . . . . . . . . . . 476.7 Resultado validación modelos complejidad media . . . . . . . . . 476.8 Resultado validación modelos complejidad baja . . . . . . . . . . 47

v

vi List of Figures

List of Tables

3.1 Criterios de comparación de las iniciativas basadas en modelos . . 17

4.1 Características evaluadas por editor grá�co . . . . . . . . . . . . 23

vii

1Introducción

1.1 Contexto

La evolución continua de las plataformas y la demanda del mercado de contar conaplicaciones en periodos muy cortos de tiempo y con presupuesto más reducidos,constituyen nuevas características a las que debe responder la construcción desoftware, características que son apoyadas por el enfoque del Desarrollo Dirigidopor Modelos, cuya �nalidad principal es ofrecer mecanismos que permiten lograrla independencia de las aplicaciones a las plataformas de desarrollo, mediante elmanejo de un nivel de abstracción adicional que permiten representar el problemay la solución por medio de modelos, usando estos modelos no solo como elementosde documentación sino como elementos a ser procesados por un herramienta, delos cuales se obtendrá el código fuente a generar de manera automática.

Este enfoque de desarrollo basado en modelos permite separar los diferentesaspectos de la representación del problema y los aspectos de la tecnología, apor-tando a la reducción de la complejidad del desarrollo por la separación de pre-ocupaciones (problema, solución y plataforma) y manejando el reto de la hetero-geneidad de las plataformas.

El Desarrollo Dirigido por Modelos puede ser aplicado a la Ingeniería web conel �n de manejar la continua evolución de las plataformas y aplicar los procesosde desarrollo web centrando el esfuerzo en la independencia de preocupacionesdel contenido, la navegación, la presentación y la arquitectura que describen laaplicación, separando estas preocupaciones y obteniendo ventajas en términos decalidad, usabilidad, reutilización y mantenibilidad.

Las herramientas que apoyan el desarrollo de software mediante modelos, ofre-cen dos tipos de alternativas de representación de los mismos, la primera consisteen una estructura de árbol, que es una estructura jerárquica que permite realizaruna organización de los elementos de los modelos del problema y de la solucióny la segunda se apoya en una sintaxis textual en lenguaje XML con la cual, pormedio de etiquetas se de�ne una estructura de organización y precedencia de loselementos del problema y la solución, alternativas que son efectivas y amigablespara la de�nición de manera rápida de los modelos que representan la aplicación.

1

2 1.2. Descripción del Problema

1.2 Descripción del Problema

Las iniciativas web basadas en modelos requieren de la de�nición de modelos inde-pendizando diferentes aspectos, como el contenido, la navegación, la presentacióny la arquitectura, en donde cada uno de estos modelos tiene la �nalidad de repre-sentar el problema y la solución desde diferentes puntos de vista, la representaciónde los mismos se realiza mediante el apoyo de las herramientas que soportan losproyectos basados en modelos. Estas herramientas ofrecen dos tipos de repre-sentaciones, la primera consiste en una estructura de árbol y la segunda se apoyaen una sintaxis textual en lenguaje XML, sin embargo, cuando se trata de larepresentación de modelos de presentación o de los formularios grá�cos con loscuales interactuará el usuario con la aplicación, estas alternativas no son su�-cientes para obtener una representación visual de los formularios que se estánde�niendo.

Para obtener una representación visual de los modelos es necesario realizaractividades como la de�nición de todos los modelos que representan la aplicación,la generación automática del código fuente, la con�guración, compilación y de-spliegue de la aplicación auto generada, con el �n de obtener un primer acer-camiento del formulario de�nido mediante el uso de modelos, adicionalmente sise evidencia la necesidad de realizar ajustes sobre los formularios obtenidos comoel uso de componentes diferentes, estilos, tamaños, colores o fuentes, es nece-sario realizarlos de manera manual ajustando los modelos de�nidos o sobre elcódigo fuente autogenerado, actividades adicionales que hacen que el proceso seadispendioso para el desarrollador de la aplicación.

Debido a la situación expuesta anteriormente se requiere contar con una nuevarepresentación para los modelos de presentación o de formularios de interfaz grá-�ca, que permita al desarrollador visualizar el formulario que se está de�niendoy evitar incurrir a actividades de la generación del código fuente y despliegue dela aplicación para obtener un primer acercamiento del formulario de�nido.

Por otro lado al contar con la representación visual del modelo de formulariossurge la necesidad de realizar ajustes sobre lo visualizado de manera interactiva,permitiendo cambios a nivel de componentes grá�cos del formulario o ajustes deforma como el tamaño, el color, la fuente y estilo de lo visualizado.

1.3 Estrategia de Solución

Con el �n de apoyar las actividades a realizar por el desarrollador de una apli-cación web en el ámbito de la creación de formularios grá�cos, se desea contar conun ambiente integrado de desarrollo con características grá�cas de visualización,que permitan ejempli�car y manipular de manera interactiva el formulario quese está diseñando. Ofreciendo, la posibilidad de usar en el formulario diferentescomponentes grá�cos y la facilidad de con�gurar el estilo que permitan captar laatención del usuario.

La estrategia de la solución propuesta se basa en extender una línea de mod-elos para el desarrollo de aplicaciones empresariales (GENIUS)[4] construida alinterior del Grupo de Construcción de Software de la Universidad de los An-des, GENIUS tiene como �nalidad integrar, a�nar y robustecer varias iniciativasespecializadas desarrolladas, entre las cuales se contempla la iniciativa para lageneración de formularios web (proyecto FORMS) y la especializada en la gen-

Introducción 3

eración de aplicaciones empresariales (proyecto MTC).

En el proyecto GENIUS consta de una serie de actividades a realizar porparte del desarrollador de la aplicación, se inicia con la de�nición del problemaen términos del negocio (modelo de dominio), se continua con el modelamiento delas funcionalidades o requerimientos que se desea la aplicación contemple(modelode casos de uso) y se procede a la ejecución de una cadena de transformación quepermiten la generación automática de los modelos de formularios grá�cos queapoyarán la aplicación y el modelo de la navegabilidad de los mismos.

Nuestra propuesta utiliza el proyecto GENIUS especí�camente en lo referenteal modelo de formularios grá�cos (Proyecto FORMS) y añade funcionalidades queapoyan las actividades a realizar por el desarrollador, ofreciendo como aporte deesta tesis, la posibilidad de tener previo a la generación automática del códigofuente una visualización de los modelos de formularios de�nidos, sobre esta vi-sualización ofrecer la opción de con�gurar los componentes de cada modelo demanera grá�ca e interactiva y proporcionar la facilidad de con�gurar el estilo quepermitan captar la atención del usuario.

Para responder al aporte previamente mencionado y a las características de-seables de una solución que apoye las actividades del desarrollador de una apli-cación web, se identi�can las siguientes alternativas de solución:

1. Crear un editor visual en el ambiente de diseño de formularios con el �n devisualizar y con�gurar los estilos de los componentes del formulario.

2. Integrar un editor visual existente en el ambiente de diseño de formula-rios con el �n de visualizar y con�gurar los estilos de los componentes delformulario.

3. Con�gurar de manera grá�ca e interactiva cada uno de los componentes delformulario.

4. Con�gurar de manera grá�ca e interactiva un grupo de componentes com-patibles del formulario.

El análisis de cada una de las alternativas propuestas se desarrollan en pro-fundidad en el capítulo 5 de implementación.

1.4 Contribución de la Tesis

Esta tesis propone una solución a los problemas de representación de los modelosde interfaz grá�ca y la con�guración de sus componentes, con el �n de obtener unarepresentación visual de los modelos de interfaz grá�ca y la posibilidad de realizarcon�guraciones de manera grá�ca e interactiva, a continuación se relacionan losaportes realizados por esta tesis:

• Trabajo de investigación inicial que permitió identi�car el problema y losretos relacionados con aplicaciones web basadas en modelos, para establecerel alcance y la contribución de esta tesis.

• Análisis y selección del editor grá�co apropiado para integrar al ambientede desarrollo de los diseñadores de modelos de formularios grá�cos.

4 1.5. Validación

• Creación de los modelos que representan los conceptos de visualización delos formularios grá�cos en el editor a integrar.

• Integración del editor al ambiente de desarrollo y a los modelos de formu-larios.

• Desarrollo para la visualización de los modelos de formularios en el editorintegrado al ambiente de desarrollo.

• Creación de los modelos de variabilidad �na por cada componente o ele-mento de los modelos de formularios.

• Desarrollo para la con�guración de la variabilidad �na por componente delmodelo de formularios.

• Actualización de los modelos de formularios según la variabilidad �na con-�gurada.

• De�nición de los aspectos de estilos a considerar en los modelos de formu-larios.

• Con�guración de estilos mediante el editor grá�co e interpretación de losmismos para la actualización de los modelos de formularios.

• De�nición y desarrollo de un caso de estudio el cual provee un ejemplo quevalida la funcionalidad completa desarrollada.

• Validación de la implementación como diferentes modelos del proyecto Academia,se usaron las métricas de desempeño utilizadas por este proyecto y se cal-culan nuevamente con el uso del desarrollo realizado.

• Artículo que resumen el propósito, implementación y contribución de estatesis.

1.5 Validación

La validación de la implementación de la propuesta realizada por esta tesis secentra en el uso de diversos modelos de formularios actualmente generados porel proyecto Academia de la Universidad de los Andes, quienes usan de maneraconstante el proyecto FORMS para dar respuesta a requerimientos de desarrollo.Se determina que se debe realizar una validación según el tipo de los modelos deformularios y se de�ne la complejidad así:

1. Baja: 1 - 15 componentes y 1-3 formularios

2. Media: 16 -26 componentes y 4 - 6 formularios

3. Alta: > 26 componentes y > 6 formularios

Se toma una muestra representativa de dos modelos de formularios del proyectoAcademia por cada grupo de complejidad de�nido para realizar la validación.

Por otro lado, el proyecto Academia cuenta con métricas de evaluación delproceso de desarrollo basado en modelos, mediciones que en el momento del de-sarrollo fueron aplicadas a los modelos de formularios que son objeto de esta

Introducción 5

validación. Se realiza la medición de los mismos criterios de estas métricas perousando la implementación realizada en esta tesis y se procede a hacer la compara-ción de las métricas obtenidas, con el �n de determinar la contribución realizada.

1.6 Organización del Documento

Este documento se encuentra constituido en siete capítulos, organizados así: In-troducción, Contexto, Estado del Arte, Estrategia de Solución, Implementación,Validación, Conclusiones y Trabajo futuro.

Capítulo 1 - Introducción: el capítulo de introducción presenta el resumen generalen el que se enmarca esta tesis, presenta un síntesis del contexto en el que se ex-plican los conceptos y generalidades de temas relacionados con MDD y MDWE,el problema que se evidencia para los modelos de formulario, la estrategia de solu-ción que se aplica para responder al problema que se evidencia, la contribuciónde la tesis y el proceso de validación del implementación realizado.

Capítulo 2 - Contexto: La propuesta cuenta con un capítulo del contexto endonde se explica en detalle las generalidades y los conceptos que de una u otraforma permiten comprender correctamente el enfoque dado a esta tesis.

Capítulo 3 - Estado del Arte: La sección del estado del arte incluye la relación delos trabajos relacionados que apoyan este aporte, se realiza la comparación en-tre las aproximaciones actuales considerando los problemas de�nidos en esta tesis.

Capítulo 4 - Estrategia de Solución: La estrategia de solución detalla las al-ternativas de solución y actividades a realizar para dar respuesta a los problemaso que se identi�caron.

Capítulo 5 - ViVaGUI: Describe la implementación de la solución, presenta eldetalle del grupo de actividades ejecutadas para dar respuesta a cada una de laslimitaciones, incluye el detalle de la implementación realizada.

Capítulo 6 - Validación: El capítulo de validación de la implementación detallarácada una de las pruebas realizadas y las métricas obtenidas con esta validación.

Capítulo 7 - Conclusiones y Trabajo Futuro: Las conclusiones y trabajo futuropresenta los bene�cios de usar la implementación realizada para las aplicacionesweb dirigida por modelos y se presentan las limitaciones que presenta la estrategiade solución.

6 1.6. Organización del Documento

2Contexto

2.1 Desarrollo de Software Basado en Modelos (MDDpor sus siglas en inglés)

La evolución continua de las plataformas y la demanda del mercado de contar conaplicaciones en periodos muy cortos de tiempo y con presupuesto más reducidos,constituyen nuevas características a las que debe responder la construcción desoftware, características que son apoyadas por el enfoque del Desarrollo Dirigidopor Modelos, el cual constituye una aproximación para el desarrollo de softwarebasada en la separación entre las funcionalidades del sistema y la implementación�nal, usando plataformas de implementación especí�cas.

Con esta aproximación se eleva el nivel de abstracción en el desarrollo desoftware dando una mayor importancia al modelado conceptual y se permite sep-arar los diferentes aspectos de la representación del problema y los aspectos dela tecnología, aportando a la reducción de la complejidad del desarrollo por laseparación de preocupaciones (negocio y plataforma) y manejando el reto de laheterogeneidad de las plataformas. Para esta aproximación un experto del nego-cio puede expresar su conocimiento en un lenguaje formal de modelado (modelode negocio) y el equipo de tecnologías de�ne los modelos que representan cómose implementará la solución (modelo de la plataforma). Con este enfoque e inde-pendencia entre el negocio y la implementación, si se desea el mismo modelo denegocio podrá implementarse en diversas plataformas como por ejemplo, JAVA,.Net y CORBA sin tanto esfuerzo.

Los artefactos principales de este paradigma de desarrollo son los modelos yla transformación de modelos, cuya �nalidad principal es realizar la integraciónentre los modelos independientes de la plataforma (modelos de negocio) y losmodelos dependientes de la plataforma (modelo de la plataforma), continuandocon una generación semi-automática de la implementación a partir de los modelos.

Los modelos como artefacto principal del paradigma de desarrollo basado enmodelos, deben cumplir con un lenguaje especí�co en términos de los conceptospropios del negocio sin considerar los detalles de la implementación, considerandoadicionalmente, la notación y las reglas que deben cumplir estos conceptos. De

7

8 2.1. Desarrollo de Software Basado en Modelos (MDD por sus siglas en inglés)

esta manera, el lenguaje que apoya la de�nición del modelo se denomina unmetamodelo.

Los metamodelos son modelos que se de�nen a partir de un lenguaje queexprese los conceptos del negocio, este lenguaje cumple con un estándar conocidocomo MOF (Meta Object Facility) [5], que es una especi�cación que abstrae laestructura, los elementos esenciales y sintaxis que describe a los metamodelos queson utilizados para construir modelos.

MOF está diseñado bajo una arquitectura de cuatro niveles de abstracciónque se les denomina comúnmente con las iniciales M3, M2, M1 y M0. El nivelM3 de�ne los elementos que constituyen el lenguaje de modelado, es decir, ellenguaje que regirá todos los metamodelos, corresponde al nivel de abstracciónmás alto. Los elementos del nivel M2 son los lenguajes de modelado que de�nenlos elementos de un dominio especí�co. En el nivel M1 se de�nen los modelos delos sistemas concretos regidos a lo de�nido en el nivel de abstracción previo M2y �nalmente, en el nivel M0 se de�nen los objetos y datos, es decir las instanciasdel sistema real. En la Figura 2.1 se presenta la arquitectura de MOF.

Figure 2.1 Arquitectura MOF

Las transformaciones como segundo artefacto del paradigma de desarrollobasado en modelos, de�nen un conjunto de elementos de entrada, unas opera-ciones y un conjunto de elementos de salida, que serán ejecutados para pasarde un modelo de origen a un modelo destino. Existen diferentes tipos de trans-formaciones dependiendo del dominio de origen y destino, los más comunes sonde modelo a modelo y de modelo a texto. El tipo de transformación de mod-elo a modelo, tiene como entrada un modelo de dominio origen y por medio deuna serie de operaciones se obtiene un modelo de dominio destino; el tipo detransformación de modelo a texto, tiene como entrada un modelo de dominioorigen y como salida el código fuente de la aplicación a generar. Este proceso seejempli�ca en la Figura 2.2 �Elementos de las transformaciones�.

Contexto 9

Figure 2.2 Elementos de las transformaciones

2.2 Ingeniería web Basada en Modelos (MDWE)

El Desarrollo Dirigido por Modelos puede ser aplicado a la Ingeniería web (MDWE)con el �n de manejar la continua evolución de las plataformas y aplicar los pro-cesos de desarrollo web, esta aproximación surge debido a la rápida expansiónde Internet y el avance en tecnologías web, permitiendo no solamente reducir loscostos y minimizar los riesgos en el proceso de desarrollo, sino también aumentarla calidad de las aplicaciones web.

Las aplicaciones web pueden dividirse en tres puntos de vista comunes, comolo es el contenido, la navegación y la presentación, preocupaciones que por mediodel enfoque dirigido por modelos son independizadas y esta descomposición endiferentes puntos de vista es la primera característica clave del enfoque basadoen modelos, logrando disminuir la complejidad del desarrollo y obtienen ventajasen términos de calidad, usabilidad, reutilización y mantenibilidad.

Para aplicar el enfoque de modelos en las aplicaciones web se aumenta elnivel de abstracción y se representan los diferentes puntos de vista involucradospor medio de modelos independientes, en donde cada modelo de�ne el conjuntode conceptos que establecen el dominio a representar, es decir, se considera unmodelo para representar el contenido, otro modelo independiente para representarla navegación y se �naliza con el modelo de presentación.

Cada uno de puntos de vista a considerar en el desarrollo de una aplicaciónweb pueden ser de�nidos, especi�cados, desarrollados y mantenidos por separadopara lograr simplicidad y reducir la complejidad, sin embargo, no son completa-mente independientes debido a que algunos elementos que representan un puntode vista en particular deben estar relacionados con elementos de las otras rep-resentaciones, con el �n de garantizar entre todas las visiones, la integridad ycoherencia de la aplicación. Esta integración se obtiene mediante el uso de unaserie de transformaciones de modelo a modelo o de modelo a texto.

En conclusión al aplicar el desarrollo de software basado en modelos a losprocesos de ingeniería web se logran manejar las características de una aplicacióndesde diferentes preocupaciones o puntos de vista y dar respuesta al problema dela evolución continua y heterogeneidad de las plataformas.

10 2.3. Variabilidad Fina y Variabilidad Gruesa

2.3 Variabilidad Fina y Variabilidad Gruesa

La variabilidad se entiende como la habilidad que tiene un sistema o un artefactode cambiar o ser personalizado para ser usada en un contexto particular.

Las aplicaciones web son la herramienta mediante la cual el usuario puedeacceder a determinada información y requiere contar con características comosencillez, rapidez y claridad en el ambiente con el que esta interactuando, poresta razón un factor importante que deben manejar los enfoques MDWE es elmanejo de la variabilidad, en este contexto la variabilidad de componentes queson cada uno de los elementos que se presentarán al usuario para su interaccióncon la aplicación.

Existen dos tipos de variabilidades, la variabilidad �na y gruesa, entendiendola variabilidad �na como la facultad o facilidad de con�gurar cada uno de loscomponentes o elementos del formulario grá�co que apoyan una aplicación y lavariabilidad gruesa consiste en aplicar determinada con�guración a un grupo decomponentes del mismo a tipo.

Para aplicar cualquier tipo de variabilidad es necesario de�nir qué compo-nentes pueden variar y de qué manera se seleccionan estos componentes en elmomento de derivar una aplicación web, esta de�nición se realiza mediante lacreación de un modelo de características, que es un modelo que de�ne cada unade las alternativas de variación que se pueden ofrecer por cada componente delformulario grá�co y que tienen que cumplir una serie de reglas o restriccionespara mantener la compatibilidad de elementos.

2.4 Representaciones de Modelos y Editores Grá�cos

Las herramientas que apoyan el desarrollo de software basado en modelos, ofrecendos tipos de alternativas de representación de los mismos, la primera consiste enuna estructura de árbol, que es una estructura jerárquica que permite realizaruna organización de los elementos de los modelos del problema y de la solución,se trata de una representación del siguiente tipo:

Figure 2.3 Representación estructura de árbol

Contexto 11

La segunda representación se apoya en una sintaxis textual en lenguaje XMLcon la cual, por medio de etiquetas se de�ne una estructura de organizacióny precedencia de los elementos del problema y la solución, como lo muestra la�gura, estas dos alternativas de representación son efectivas y amigables para lade�nición de manera rápida de los modelos que representan la aplicación.

Figure 2.4 Representación sintaxis textual

Sin embargo, cuando se trata de una aplicación web y se requiere la de�niciónde modelos de formularios y los componentes grá�cos que los conforman, estasrepresentaciones no son su�cientes para el desarrollador de la aplicación, debidoa que no es posible interactuar con una herramienta grá�ca que le proporcioneuna representación visual del formulario que está de�niendo, para solucionar estasituación se puede hacer uso de un editor grá�co.

Un editor grá�co para interfaces de usuario, son herramientas que brindan laalternativa de visualización y edición de formularios de forma interactiva, tienencomo �nalidad visualizar en tiempo real lo que se espera obtener aplicando elparadigma WYSIWYG (What You See Is What You Get), lo que ves es lo queobtienes, es decir, diseñar un formulario grá�co viendo directamente el resultado�nal.

Existen varios tipos de editores grá�cos que pueden basarse en especi�cacionespropietarias o libres, di�eren del tipo de componentes que usan (AWT, Swing,SWT)[6], su representación y comportamiento. Un editor grá�co frecuentementese compone de una paleta de componentes visuales, la representación grá�ca deun formulario y en ocasiones presentan el código fuente que apoyan esta repre-sentación grá�ca.

12 2.4. Representaciones de Modelos y Editores Grá�cos

3Estado del Arte

Existen varias iniciativas que usan el enfoque de la Ingeniería web basadas enmodelos y permiten dar respuesta a las necesidades del mercado de manejar lacontinua evolución de las plataformas y aplicar los procesos de desarrollo web.Estas iniciativas centran el esfuerzo en la independencia de preocupaciones delcontenido, la navegación, la presentación, la arquitectura y demás puntos de vistainvolucrados para describir una aplicación web.

A continuación, se describe el funcionamiento y alcance de un grupo de ini-ciativas actuales basadas en modelos, sus estrategias y limitantes.

3.1 UWE (UML-based web Engineering)

UWE [7] es una iniciativa que aplica el enfoque del desarrollo web basado enmodelos y permite la generación de aplicaciones web mediante la de�nición deuna serie de modelos independientes de la plataforma, la aplicación de una serie detransformaciones para generar la solución en una plataforma especí�ca y �nalizarcon la generación del código fuente de la aplicación.

Esta iniciativa usa como lenguaje de notación UML por medio de la de�niciónde un per�l que permite la representación de los modelos de la aplicación.

UWE maneja diferentes puntos de vista para de�nir una aplicación, entreestos se considera la vista de negocio, navegación, proceso y presentación, cadauno de estos modelos representan una perspectiva diferente de la aplicación yconsideran los siguientes aspectos:

• Modelo de contenido: Considera todos los conceptos, relaciones y contratosdel negocio que dan respuesta a los requerimientos funcionales de la apli-cación, se representa por medio de un Diagrama de clases.

• Modelo de navegación: La de�nición de este modelo consta de cinco pasosfundamentales que consisten en:

� Asociación de los conceptos del negocio con los metaconceptos de�nidospara el per�l UML notado como ìNavigationClassî.

13

14 3.2. UCEd (Use Case Editor)

� Creación del Menú que corresponde al conjunto de opciones que seofrecerán al usuario.

� De�nición de consultas que corresponde a opciones de consulta que sepueden establecer, para esta funcionalidad se usa el per�l ìQueryî.

� De�nición de las operaciones a realizar sobres los conceptos o entidadesdel negocio como por ejemplo, creación, actualización o eliminación.

� Asociación de los conceptos del negocio por medio del per�l ìLinkî lascuales determinan las rutas de navegación.

• Modelo del proceso: En este modelo se de�nen las actividades del �ujo delas funcionalidades, se establecen los datos que son intercambiados con elusuario durante el proceso, asociando los conceptos de los formularios webcon las operaciones del negocio, mediante el uso de un per�l UML notadospara estas representaciones.

• Modelo de presentación: Este modelo se representa por medio de un di-agrama de clases y modela la distribución de los formularios grá�cos queapoyarán la aplicación, sus componentes y los puntos de interacción con elusuario.

En resumen esta estrategia separa diferentes puntos de vista en los modelosde contenido, navegación, proceso y presentación, los cuales deben ser de�nidosde manera manual por el desarrollador de acuerdo a los requerimientos de laaplicación. Las correspondencias entre estos modelos son manejadas a través delos nombres de los conceptos, los cuales deben coincidir en los diferentes puntosde vista.

Las limitantes de esta aproximación son: La modi�cación manual de los mod-elos para manejar la variación de los productos generados, el acoplamiento deconceptos de navegación y de negocio que se genera en la de�nición del mod-elo de procesos y el manejo informal de las correspondencias de los diferentespuntos de vista, lo cual, di�culta la evolución de los modelos, su reutilización ymantenimiento independiente.

3.2 UCEd (Use Case Editor)

UCEd [8] es una aproximación que aplica el enfoque del desarrollo web basado enmodelos y de�ne un método semi-automático para la generación de aplicacionesweb a partir de la de�nición de los requerimientos expresados por medio de casosde uso.

Esta iniciativa consta la de�nición de dos tipos de modelos que expresan losrequerimientos de una aplicación web, se inicia con la de�nición de los casos deuso que expresan los requerimientos funcionales de la aplicación web y se culminacon una autogeneración del modelo de dominio donde se establecen conceptos,relaciones y contratos del negocio que deben ser re�nados de manera manual porel desarrollador, estos modelos son usados para producir de manera automáticauna máquina de estados. A partir de esta máquina de estados se crea un modelode interfaz por defecto el cual debe ser re�nado de manera manual por el de-sarrollador y �nalmente, usando estos modelos producidos se genera un modeloespecí�co de la plataforma para generar el código fuente de la aplicación web.

Estado del Arte 15

UCEd es una aproximación en el contexto del desarrollo web basado en mod-elos que tiene en cuenta un modelo que expresa el problema en términos de losrequerimientos funcionales. Sin embargo, el modelo de interfaz presenta unasemántica limitada para expresar conceptos web, no cuenta con un mecanismocentrado en usuario para la visualización de los modelos de formularios y la ad-ministración de la variabilidad, adicionalmente maneja de manera informal lascorrespondencias entre los diferentes puntos de vista, lo cual, di�culta la evoluciónde los modelos, su reutilización y mantenimiento.

3.3 MD-WEB-SPL (Líneas de Producto de Softwarepara Aplicaciones web Dirigida por Modelos)

MD-WEB-SPL [9] es una iniciativa que aplica el enfoque del desarrollo webbasado en modelos y permite la generación de aplicaciones web mediante la de�ni-ción de una serie de modelos independientes de la plataforma, la aplicación de unaserie de transformaciones para generar la solución en una plataforma especí�cay �nalizar con la generación del código fuente de la aplicación.

Esta aproximación cuenta con modelos de negocio, interacción, corresponden-cia, navegación y características, se inicia con el primer modelo que correspondea la de�nición del modelo de negocio de la aplicación que de�ne las entidadesrelevantes, sus atributos, contratos y relaciones que representan el contexto delnegocio, el segundo modelo es el de interacción en donde se de�nen los requer-imientos del negocio, en términos de los �ujos de interacción existentes entre elusuario y el sistema, representa el problema y las funcionalidades en términos ex-clusivos de los conceptos del negocio, sin utilizar conceptos del dominio web. Eltercer modelo es el de correspondencias representa las relaciones que se establecenentre los elementos del modelo de interacción con los elementos del modelo denegocio. El cuarto modelo es el primer paso dentro del espacio de solución se gen-era de manera automática el modelo de navegación considerando como insumoslos modelos previamente de�nidos. Sobre el modelo de navegación se de�ne lospuntos de variación de las aplicaciones web en términos de sus atributos grá�cos,esta variación constituye el modelo de características.

Esta aproximación tiene en cuenta un modelo que expresa el problema entérminos de los requerimientos funcionales, cuenta con un mecanismo centrado enusuario para administrar la variabilidad y maneja las correspondencias entre losdiferentes puntos de vista, sin embargo, no cuenta con un mecanismo centrado enusuario para la visualización de los modelos de formularios afectando la evoluciónde los modelos, su reutilización y mantenimiento.

3.4 GENIUS (Aproximación para la generación de in-terfaces web de aplicaciones empresariales basadasen patrones de casos de uso)

GENIUS es una iniciativa que aplica el enfoque del desarrollo web basado enmodelos y permite la generación de aplicaciones mediante la de�nición estructuraly de comportamiento del problema usando patrones. Esta aproximación cuentacon modelos de negocio y casos de uso, los cuales se describen a continuación:

16 3.5. Discusión

• Modelo de negocio: Corresponde a la de�nición de las entidades relevantes,sus atributos, contratos y relaciones que representan el contexto del negocio.

• Modelo de casos de uso: Se de�nen los requerimientos funcionales del ne-gocio.

En esta aproximación la de�nición del patrón contiene la información su�-ciente para generar un �ujo de interacción con el usuario y el conjunto de serviciosnecesarios para satisfacer los requerimientos. Se ejecuta una cadena de transfor-maciones que generan de manera automática los modelos que representan losdiferentes puntos de vista de la aplicación web de la siguiente manera:

• Modelo de interacción: Este modelo representa la anidación entre los con-ceptos del negocio y las funcionalidades de�nidas.

• Modelo de aplicación: Este modelo integra el negocio en términos de enti-dades y funcionalidades del negocio.

• Modelo de presentación: Representa los elementos de interacción web, esdecir los formularios grá�cos que apoyarán la aplicación.

• Modelo de navegación: Representa el �ujo entre los formularios de la apli-cación.

Después de la generación automática de estos modelos se procede a ejecu-tar una cadena de transformaciones que genera los modelos dependientes a laplataforma y el código fuente de la solución.

Esta aproximación en el contexto del desarrollo web basado en modelos quetiene en cuenta un modelo que expresa el problema en términos de los requer-imientos funcionales. Sin embargo, no cuenta con un mecanismo centrado enusuario para la visualización de los modelos de formularios y la administraciónde la variabilidad, lo cual, di�culta la evolución de los modelos, su reutilizacióny mantenimiento.

3.5 Discusión

Existen varias aproximaciones en el contexto de la ingeniería web basada enmodelos (MDWE) que reducen la complejidad de las aplicaciones mediante laseparación de preocupaciones en diferentes puntos de vista y manejan el problemade la heterogeneidad de las plataformas. Sin embargo, es necesario realizar unanálisis comparativo enfocado en las necesidades que se plantean en esta tesispara esto se ha de�nido un conjunto de criterios de comparación relacionados demanera directa con los problemas planteados en esta tesis.

Se realiza la identi�cación de los criterios de comparación relevantes que debenofrecer estas aproximaciones y que se centran en de�nir claramente una indepen-dencia en cada nivel conceptual que hacen parte de una aplicación y aportan aldesarrollador facilidades para la de�nición e interacción con los modelos de lasolución, estos criterios corresponden a:

• Representación del problema en términos del negocio: Consiste en la ca-pacidad de poder representar el comportamiento del negocio, en términosdiferentes a los conceptos propios del dominio web.

Estado del Arte 17

• Representación del problema en el dominio web: Representación del prob-lema en términos de los conceptos propios del dominio web.

• Generación personalizada de los formularios de la aplicación web: Considerala de�nición a la medida de los modelos de formularios y componentesgrá�cos que apoyan la aplicación.

• Visualización de los formularios web de�nidos: Consiste en la capacidad deinteractuar de manera grá�ca sobre el formulario de�nido, sin incurrir enlas actividades de la generación del código fuente.

• Variabilidad de los componentes que conforman el formulario: Considera lacon�guración de manera interactiva de la variabilidad de los componentesgrá�cos de un formulario, sin incurrir en las actividades de la generacióndel código fuente.

A continuación se relaciona por cada una de las aproximaciones considerandoel cubrimiento de los criterios previamente descritos.

Criterio UWE UCEd MD-WEB-SPL GENIUS

Representación del problema en tér-minos del negocio

Si Si Si Si

Representación del problema en eldominio web

Si Si Si Si

Generación personalizada de los for-mularios de la aplicación web

No Si Si Si

Visualización de los formularios webde�nidos

No No No No

Variabilidad de los componentes delos formularios web

No No Si No

Table 3.1 Criterios de comparación de las iniciativas basadas en modelos

El análisis comparativo de los criterios de�nidos, muestra que las aproxima-ciones web basadas en modelos de este estudio, generalmente, adolecen de unarepresentación visual de los modelos de formularios y de su manipulación de man-era grá�ca, para realizar con�guraciones como la variabilidad de componentesgrá�cos y estilos de los mismos. El detalle de estas necesidades identi�cadas serealiza en el siguiente capítulo.

18 3.5. Discusión

4Estrategia de Solución

Nuestro propósito es ofrecer un ambiente integrado de desarrollo con caracterís-ticas grá�cas de visualización, que permitan obtener una visualización y ma-nipulación de manera interactiva de los formularios web construidos a partir demodelos, considerando la posibilidad variar en el formulario los diferentes com-ponentes grá�cos y la facilidad de con�gurar el estilo que permitan captar laatención del usuario. Para cumplir este propósito se han identi�cado las sigu-ientes necesidades:

1. Visualizar el modelo de formularios que se está diseñando.

2. Con�gurar la variabilidad por componente grá�co, permitiendo el ajuste delos componentes visualizados por elementos compatibles de representación.

3. Con�gurar las propiedades de estilo como color, fuente y tamaños sobre elformulario, con el �n de captar la atención del usuario.

Para abordar estas tres necesidades estructuramos nuestra estrategia en lassiguientes secciones, primero presentamos el detalle de GENIUS como línea denegocio que se extenderá para ofrecer nuevas funcionalidades que permitan dar re-spuesta a las necesidades identi�cadas, continuamos con las posibles alternativasde solución identi�cadas y factibles a desarrollar y culminamos con la alternativaseleccionada, que es la implementada por nuestra tesis.

4.1 GENIUS

Para dar respuesta a las necesidades previamente identi�cadas, nuestra estrate-gia se basa en extender la línea de modelos para el desarrollo de aplicaciones(GENIUS) construida al interior del Grupo de Construcción de Software de laUniversidad de los Andes. GENIUS tiene como �nalidad integrar, a�nar y ro-bustecer varias iniciativas especializadas desarrolladas, entre las cuales se con-templa la iniciativa para la generación de formularios web (proyecto FORMS) yla especializada en la generación de aplicaciones empresariales (proyecto MTC).

19

20 4.1. GENIUS

Como se mencionó en el capítulo anterior el proyecto GENIUS en términosgenerales consta de las siguientes actividades a realizar por parte del desarrolladorde la aplicación:

1. Actividad 1. Modelos del problema: Se inicia con la de�nición del problemaen términos del negocio (modelo de dominio) y el modelamiento de las fun-cionalidades o requerimientos que se desea la aplicación contemple(modelode casos de uso).

2. Actividad 2. Modelo de interacción: Se procede a la ejecución de una ca-dena de transformación que incluye el modelo patrón a usar (Maestro/De-talle) y que permite la generación automática del modelo de interacción dela aplicación, cuya �nalidad es realizar la anidación entre los conceptos delnegocio y las funcionalidades de�nidas.

3. Actividad 3. Modelo de la aplicación: Se ejecuta una transformación quegenera de manera automática el modelo de la aplicación considerando lasfuncionalidades de�nidas en los dos puntos previos, los siguientes pasos aaplicar son:

3.1 Ejecución de manera automática de una serie de transformaciones quepermiten generar el código fuente de la aplicación en términos de en-tidades y funcionalidades del negocio.

4. Actividad 4. Modelo de formularios: Se ejecuta una cadena de transfor-mación que genera de manera automática el modelo de formularios grá�cosque apoyarán la aplicación, en este momento se procede a realizar:

4.1 Ejecución de manera automática de una serie de transformaciones quepermiten generar el código fuente de la aplicación en términos de losformularios grá�cos que apoyarán la aplicación.

5. Actividad 5. Modelo de navegación: Se ejecuta una cadena de transforma-ción que genera de manera automática el modelo de la navegabilidad de losformularios grá�cos de la aplicación, en este momento se procede a realizar:

5.1 Ejecución de una transformación para la generación del modelo denavegación en una tecnología de�nida en este caso GWT [10].

5.2 Después de la generación del modelo de navegación en GWT se ejecutauna transformación para la generación automática del código fuentede la aplicación en términos de comunicación entre los formularios grá-�cos de la aplicación.

A continuación se representan de manera grá�ca las actividades enumeradaspreviamente y que conforman el proceso de la línea de negocio GENIUS.

Estrategia de Solución 21

Figure 4.1 Proceso GENIUS

Nuestra propuesta utiliza el proyecto GENIUS especí�camente en lo referenteal modelo de formularios grá�cos (Actividad 4. Modelo de formularios) y añadefuncionalidades que apoyan las actividades a realizar por el desarrollador, ofre-ciendo como aporte de esta tesis, la posibilidad de tener previo a la generaciónautomática del código fuente una visualización de los modelos de formulariosde�nidos, sobre esta visualización ofrecer la opción de con�gurar la variabili-dad por componentes compatibles de manera grá�ca e interactiva y proporcionarla facilidad de con�gurar el estilo que permitan captar la atención del usuario.Generando las nuevas actividades así:

4 Actividad 4. Modelo de formularios: Se ejecuta una cadena de transfor-mación que genera de manera automática el modelo de formularios grá�cosque apoyarán la aplicación, en este momento se propone realizar las sigu-ientes actividades:

4.1 Visualización apoyada por un editor grá�co del modelo de formulariosgrá�cos generado de manera automática.

4.2 Con�guración de la variabilidad por componente grá�co, permitiendoel ajuste de los componentes visualizados por elementos compatiblesde representación y posterior actualización automática del modelo deformularios.

4.3 Con�guración de estilos sobre los formularios considerando fuentes,colores y tamaños de cada uno de los componentes, en este punto serealizaría una actualización automática del modelo de formularios yla creación del archivo de estilos de la aplicación.

Los puntos previamente mencionados serían puntos opcionales de uso por eldesarrollador de la aplicación, si no es necesario realizarlos el proceso puede seguircon su �ujo normal sin afectación. A continuación se resaltan en color naranjalas actividades adicionales a realizar.

22 4.2. Alternativas de Solución

Figure 4.2 Proceso ViVaGUI

4.2 Alternativas de Solución

Para dar respuesta a las tres necesidades identi�cadas previamente y a las carac-terísticas deseables de una solución que apoye las actividades del desarrollador deuna aplicación web, se identi�ca que pueden ser resueltos de diferentes manerasy se plantean las siguientes alternativas de solución:

1. Crear un editor visual en el ambiente de diseño de formularios con el �n devisualizar y con�gurar los estilos de los componentes del formulario.

2. Integrar un editor visual existente en el ambiente de diseño de formula-rios con el �n de visualizar y con�gurar los estilos de los componentes delformulario.

3. Con�gurar de manera grá�ca e interactiva cada uno de los componentes delformulario.

4. Con�gurar de manera grá�ca e interactiva un grupo de componentes com-patibles del formulario.

A continuación se presenta un análisis de cada alternativa de solución y laexplicación detallada de la alternativa propuesta por esta tesis.

1. Crear un editor visual en el ambiente de diseño de formularios:

Esta alternativa de solución consiste en la creación de un editor visual enel ambiente del diseño de los modelos de formularios, requiere del desar-rollo de un editor que permita mostrar de manera grá�ca cada uno de loscomponentes que conforman un formulario, adicionalmente se requiere queel desarrollo cuente con la posibilidad de interactuar sobre cada uno delos componentes que se están visualizando y se ofrezca la posibilidad decon�gurar los estilos, tamaños y colores de cada uno de ellos.

2. Integrar un editor visual existente en el ambiente de diseño de

formularios:

Esta alternativa de solución consiste en la integración de un editor visualen el ambiente de diseño de modelos de formularios, para esta alternativa


se realiza el análisis de diversos editores como lo son Window Builder[11],SWIXML[12], RedView[13] y XWT[14], se evalúan características comocompatibilidad con eclipse por ser el ambiente de desarrollo de modelosusado para el proyecto GENIUS, cantidad de elementos grá�cos inclui-dos con el �n de contemplar mínimo los usados en el modelos de formula-rios FORMS, posibilidad de extensión para la integración de nuevos com-ponentes si es necesario, edición y aplicación del paradigma WYSIWYG(What You See Is What You Get) y fácil edición de formularios de maneragrá�ca e interactiva.

Se procede a realizar una prueba con cada uno de los editores grá�cosmencionados y se evalúan cada uno de los criterios obteniendo:

CRITERIO XWT SwiXml Redview Window Builder

Compatibilidad coneclipse (Si 5, No 2)

5 5 5 5

Elementos grá�cos in-cluidos (40 comp 5 y 30comp 3)

5 5 5 5

Posibilidad de extensión(Si 5, No 2)

5 5 5 5

Edición WYSIWYG (Si5, No 2)

5 5 5 5

Fácil Edición (Si 5, No2)

5 5 2 2

TOTAL 25 25 22 22

Table 4.1 Características evaluadas por editor grá�co

La evaluación de estas características determina que el editor XWT es elmás apropiado a usar, debido a que está inmerso en el ambiente de de-sarrollo Eclipse, soporta los componentes que maneja el actual modelo deformularios del proyecto FORMS y es de fácil uso, cumple con las carac-terísticas que se desean ofrecer al usuario que interactuará con el editor grá-�co. Adicionalmente por ser un editor que genera automáticamente códigoXML tiene un mayor nivel de compatibilidad con los proyectos basados enmodelos y se podría generar automáticamente este código.

3. Con�gurar de manera grá�ca e interactiva cada uno de los com-

ponentes del formulario:

Esta alternativa propone la con�guración de la variabilidad de cada uno delos componentes, es decir, ofrecer la facilidad de con�gurar cada uno de loselementos del formulario grá�co de manera independiente, conociendo estacon�guración como variabilidad �na.

24 4.3. Alternativa Seleccionada

Considera cada componente del formulario como un elemento independientepara el cual se puede establecer una con�guración especial, ofreciendo lafacilidad de de�nir por componente como se quiere representar.

4. Con�gurar de manera grá�ca e interactiva un grupo de compo-

nentes compatibles del formulario:

Esta alternativa propone la con�guración por grupo de componentes, esdecir, que todos los componentes que cumplen con una misma funcionalidadse representarán de una única manera y se de�niría una única con�guraciónpor grupo de componentes compatibles y esta sería aplicada de la mismamanera a todos los componentes del mismo tipo del formulario, conociendoesta con�guración como variabilidad gruesa.

Para las dos alternativas de con�guración de la variabilidad sea �na o gruesaes necesario de�nir qué componentes pueden variar y de qué manera se se-leccionan estos componentes en el momento de derivar una aplicación web,esta de�nición se realiza mediante la creación de un modelo de característi-cas, que es un modelo que de�ne cada una de las alternativas de variaciónque se pueden ofrecer por cada componente del formulario grá�co y quetienen que cumplir una serie de reglas o restricciones para mantener lacompatibilidad de los elementos.

Para la de�nición de los modelos de características y de los de modelos derestricciones se hace el uso de la implementación realizada para el proyectoFieSta [15], el cual es una estrategia basada en el desarrollo dirigido pormodelos para el manejo de variabilidad. FieSta provee mecanismos paraexpresar la variabilidad de líneas de producto de software, estos mecanismosson soportados por dos modelos: el modelo de features y el modelo derestricciones.

El modelo de features es un modelo que permite de�nir la posible variabili-dad que pueda existir en una línea de producto. El metamodelo de featurescreado se basa en la metodología expuesta por Czarnekqui. [16]

El modelo de restricciones permite limitar el alcance de la línea creandorestricciones a las posibles con�guraciones que pueda realizar un desarrol-lador de un elemento especí�co de un producto.

4.3 Alternativa Seleccionada

Las alternativas uno y cuatro no se considera la mejor opción de solución parael problema identi�cado, la primera debido a que no es la solución más óptimaporque existen diversos editores visuales actualmente integrados en el ambiente dedesarrollo de modelos de Eclipse y se considera menos costoso el uso de un editorexistente en esta plataforma, que el desarrollo de un nuevo editor, centrandoel esfuerzo en otras actividades del aporte y no a un desarrollo con el cual yase cuenta. Por otro lado, la cuarta alternativa se descartada por que restringeal desarrollador las posibilidades de con�guración independiente de elementos,debido a que estos se harían de manera masiva y no de manera individual, seconsidera un mayor aporte si se con�guran los componentes de manera individualporque se logra obtener un mayor grado de personalización de los formularios.


Como propuesta nuestra tesis determina que las alternativas que mejor apoyanlas actividades del desarrollador de modelos de formularios es la unión de las alter-nativas dos y tres, que consisten integrar un editor visual al ambiente de desarrolloy con�gurar la variabilidad por cada componente del formulario, alternativas queresponden a la necesidad de contar con un ambiente integrado de desarrollo concaracterísticas grá�cas de visualización, que permitan ejempli�car y manipularde manera interactiva el formulario de�nido mediante el uso de modelos.

En resumen la alternativa seleccionada ViVaGUI (Visualización y Variabili-dad de los fomularios de Interfaz Grá�ca de Usuario), responderá a cada una delas necesidades de la siguiente manera:

1. Visualizar el modelo de formularios que se está diseñando:

Para responder esta necesidad realizaremos el desarrollo requerido paraobtener la integración del editor visual XWT con el modelo de formulariosdel proyecto FORMS.

2. Con�gurar la variabilidad por componente grá�co, permitiendo el

ajuste de los componentes visualizados por elementos compatibles

de representación:

Esta necesidad la resolveremos mediante el uso de la implementación real-izada por el proyecto FieSta para la de�nición de los modelos de variabili-dad de componentes (features) y el modelo de restricciones. Adicionalmenterealizaremos el desarrollo requerido para ofrecer sobre la visualización delformulario la posibilidad de seleccionar la con�guración de los componentespor elementos compatibles y la actualización del modelo de formularios demanera automática según la con�guración realizada.

3. Con�gurar las propiedades de estilo como color, fuente y tamaños

sobre el formulario, con el �n de captar la atención del usuario:

Para lograr la con�guración de los estilos de los formularios realizaremosuna integración entre las actividades realizadas por el desarrollador sobre lavisualización del formulario mediante el uso del editor, en lo que respecta alas con�guraciones de estilos (fuentes, colores y tamaños) y las aplicaremossobre el modelo de formularios para posteriormente realizar la generacióndel archivo de estilos de la aplicación.

El detalle de las actividades que resuelven cada una de estas necesidades sepuntualiza en el capítulo 5 ViVaGUI.

26 4.3. Alternativa Seleccionada

5ViVaGUI

5.1 Visión General

En este capítulo presentamos el alcance y la manera como implementamos laalternativa seleccionada ViVaGUI, a continuación, relacionamos el detalle de ac-tividades a considerar por cada una de las necesidades identi�cadas:

Visualizar el Modelo de Formularios Grá�cos

1. Creaar el metamodelo de los componentes que soporta el editor grá�coXWT.

2. Realizar una transformación de modelo a modelo entre el modelo de for-mularios y modelo del editor XWT.

3. Realizar una transformación de modelo a texto entre el modelo del editorXWT y el archivo XML que representa el formulario en el editor.

4. Generar un plugin en Eclipse que permita sobre el modelo de formulariosgenerar de manera automática la visualización en el editor grá�co de XWT.

Con�gurar la Variabilidad por Componente Grá�co

1. Crear el modelo de características (features) que de�ne los elementos com-patibles de representación.

2. Crear el modelo de restricciones que establece la cantidad posible de con�g-uraciones que se pueden realizar por componente y permite la integracióncon el modelo de formularios.

3. Generar un plugin en Eclipse que permita mostrar al usuario por compo-nente del formulario las posibles alternativas de variación para su con�gu-ración.

4. Actualizar el modelo de formularios aplicando la con�guración realizadapor el desarrollador de la aplicación.

27

28 5.2. Visualizar el Modelo de Formularios Grá�cos

Con�gurar los Estilos sobre los Formularios

1. Sobre la visualización del formulario grá�co en el editor, usar las funcional-idades que este provee para realizar los ajustes en cuanto fuente, color ytamaño por componente.

2. Actualizar el modelo de formularios para contemplar los estilos con�guradospor medio del uso del editor.

3. Generar según los estilos con�gurados el archivo de estilos CSS (CascadingStyle Sheets por sus siglas en ingles) que se usarán para la aplicación.

Se presenta de manera grá�ca cada una de las actividades enumeradas previ-amente:

Figure 5.1 Proceso ViVaGUI

5.2 Visualizar el Modelo de Formularios Grá�cos

En esta sección se detalla cada una de las actividades, metamodelos, transfor-maciones y herramientas de soporte implementadas que permiten dar respuestaa esta necesidad. Como primera instancia, explicamos el metamodelo de formu-larios como parte del contexto, se continúa con el metamodelo del editor grá�coXWT. En seguida, se explica las transformaciones entre modelos y texto real-izadas y �nalmente, se explica la herramienta de soporte para la visualización delos modelos de formularios.

5.2.1 Metamodelo de Formularios (FORMS)

De�ne los conceptos estructurales del espacio de los formularios, es decir, la or-ganización de los conceptos de formularios y sus atributos. El modelo completode formularios se abstrae con el concepto Module que representa la asociaciónentre los proyectos de formularios de una aplicación, el concepto Project es unconcepto de agrupación y representa un conjunto de formularios, para �nalizarel concepto Models Container representa el grupo de conceptos del negocio aso-ciados a los formularios, este es el punto de anidación con el modelo de negocio,como lo representa la siguiente �gura:

ViVaGUI 29

Figure 5.2 Metamodelo Forms

Por otro lado, el metamodelo de formularios se agrupa en cinco paquetesdiferentes según el grupo de conceptos a representar estos paquetes son el Core,FormElements, Model, Events e Internationalization. Se inicia con el paqueteCore que agrupa los conceptos comunes para todos los formularios.

Figure 5.3 Metamodelo Forms Paquete Core

Se continúa con el paquete FormElements que contiene la representación decada uno de los elementos que pueden componer los formularios y sus relaciones.Se considera elementos principales como botones, tablas, listas y campos y cadauna de sus diferentes representaciones. La parte más representativa del meta-modelo se muestran a continuación.

Figure 5.4 Metamodelo Forms Paquete FormElements


Se presentan cada uno de los conceptos que representan el modelo del negocioy están incluidos en el paquete Model.

Figure 5.5 Metamodelo Forms Paquete Model

Se agrupan los eventos sobre algunos componentes de los formularios comolos botones en el paquete denominado Event.

Figure 5.6 Metamodelo Forms Paquete Event

Se �naliza con el paquete de internationalization que maneja cada uno de losnombres, labels y mensajes que se presentarán en los formularios de la aplicación.

Figure 5.7 Metamodelo Forms Paquete Internationalization

ViVaGUI 31

5.2.2 Metamodelo del Editor Grá�co XWT

El metamodelo del editor grá�co de XWT contiene todos los conceptos que per-miten representar cada uno de los elementos de un formulario en una repre-sentación visual en el editor. Usa como elementos principales el concepto Moduleque realiza la asociación entre todos los proyectos que se pueden crear para laaplicación y el concepto Project que agrupa los formularios que apoyarán la apli-cación.La parte más representativa del metamodelo se muestran a continuación.

Figure 5.8 Metamodelo XWT

Este metamodelo agrupa en el paquete XWTElements la representación de loselementos del formulario, considera elementos principales como botones, tablas,listas y campos y cada una de sus diferentes representaciones. Se presenta acontinuación una muestra de los elementos que se consideran.

Figure 5.9 Metamodelo XWT


5.2.3 Transformación de Modelo a Modelo (Forms2XWT)

Forms2XWT es un conjunto de reglas de transformación de modelo a modelo endonde cada uno de los conceptos del modelo de formularios que hacen referencia ala visualizacón se convierten en conceptos de representación del modelo del editorXWT, este es el primer paso para poder obtener una representación visual delmodelo. En la siguiente �gura se presentan las primeras reglas de transformaciónde este grupo de reglas.

Figure 5.10 Transformación Forms2XWT

Al aplicar este conjunto de reglas de transformación del modelo Forms almodelo XWT se obtiene una representación del formulario en términos de losconceptos manejados por el editor visual.

5.2.4 Transformación de Modelo a Texto (XWT2Text)

XWT2Text es un conjunto de reglas de transformación de tipo modelo a texto endonde cada uno de los conceptos que representan un elemento del formulario setransforman en un archivo XML que considera un tipo de etiqueta diferente porcada elemento grá�co del formulario, esta transformación tiene como elementode entrada el modelo de XWT y como elemento de salida el archivo XML queinterpretará el editor. En la siguiente �gura se presentan las primeras reglas detransformación de este grupo de reglas.

Al aplicar este conjunto de reglas se genera como producto el archivo XMLque el editor visual XWT interpreta para representar de manera grá�ca cada unode los componentes del formulario.

ViVaGUI 33

Figure 5.11 Tranformación XWT2Text

5.2.5 Herramienta de Visualización

Como herramienta de visualización se desarrolla un plugin en Eclipse para vi-sualizar el modelo de formularios al realizar un click, este plugin tiene comoelemento de entrada el modelo de formularios, internamente genera el modelo derepresentación en el editor XWT y genera como elemento de salida el archivoXML que el editor visual interpretará para mostrar grá�camente el formulario.

Los usuarios de este plugin están representados por el desarrollador de la apli-cación, quienes seleccionan la pantalla que desean visualizar representada porel concepto Form en el modelo de formularios, usan la funcionalidad del pluginllamada Preview y ven de manera grá�ca el formulario seleccionado. A contin-uación se muestra el funcionamiento de este plugin como herramienta.

1. Se ofrece la funcionalidad Preview sobre el modelo de formularios que sedesea visualizar.

34 5.3. Con�gurar la Variabilidad por Componente Grá�co

Figure 5.12 Ejecución de la visualización del modelo de formularios

2. Automáticamente se generará el código XML que el editor XWT entiendeen interpreta para obtener una visualización con la siguiente:

Figure 5.13 Visualización del modelo de formularios

De esta manera se obtiene la visualización del modelo de formularios selec-cionado, esta visualización se puede realizar la cantidad de veces que se considerenecesario sin afectar el modelo de formularios, debido a que se trata de unafuncionalidad que no actualiza o ajusta el modelo.

5.3 Con�gurar la Variabilidad por Componente Grá�co

En esta sección se detalla cada una de las actividades, modelos y herramientas desoporte que permiten dar respuesta a esta necesidad. Como primera instancia,explicamos la creación del modelo de características y restricciones. En seguida,se explica la generación del plugin de eclipse que permite la con�guración de lavariabilidad. Finalmente, se explica la actualización del modelo de formulariosque se realiza.

ViVaGUI 35

5.3.1 Creación del Modelo de Características

Para la creación del modelo de características como se mencionó previamente sehizo uso del plugin generado por el proyecto FieSta, en donde se pueden de�nirlos elementos compatibles de representación que pueden ser con�gurados. Laserie de pasos a realizar se muestran a continuación.

Figure 5.14 Creación del modelo de características

El modelo de características de variabilidad de�nido para los elementos delformulario se realiza según el tipo de dato que representa el componente, es decir,los tipos de dato String pueden ser representados por medio de componentes com-patibles como TextField, TextArea y LabelField, para cada uno de los diferentestipos se de�ne la variabilidad y se representan así:

Figure 5.15 Modelo de características

36 5.3. Con�gurar la Variabilidad por Componente Grá�co

5.3.2 Creación del Modelo de Restricciones

Para la creación del modelo de restricciones como se mencionó previamente sehizo uso del plugin generado por el proyecto FieSta, en donde se pueden de�nir lacantidad mínima y máxima de los tipos de elementos que pueden ser con�guradosen un formulario y determinar la asociación con los conceptos del modelo deformularios. La serie de pasos a realizar se muestran a continuación.

Figure 5.16 Creación del modelo de restricciones

El modelo de restricciones de�nido para los elementos del formulario se realizasegún la cantidad de elementos que se puedan con�gurar por cada componente delformulario y se de�ne la relación con cada concepto del formulario que representanasí:

ViVaGUI 37

Figure 5.17 Modelo de restricciones

5.3.3 Plugin de Eclipse para Con�gurar la Variabilidad

Con el �n de con�gurar la variabilidad por cada uno de los elementos del for-mulario se realiza el desarrollo de un plugin en Eclipse que identi�ca el tipode componente de cada elemento del modelo de formularios (String, Collection,Date, entre otros) y presenta las posibles alternativas de variabilidad a con�gurarsegún el modelo de características y de restricciones de�nidos previamente, conel �n que el desarrollador seleccione el componente que desea con�gurar así:

Figure 5.18 Con�gurar la variabilidad

Posterior a la selección realizada por parte del desarrollador para aplicar lacon�guración que desea sobre los componentes del formulario que lo requieren,este plugin realiza tres actividades principales, inicia con la actualización au-tomática del modelo de formularios cuya �nalidad es cambiar los componentesque fueron con�gurados certi�cando la conformidad del modelo, continua con lanueva generación del modelo XWT y �naliza con la transformación a texto delformulario XWT para visualización de los cambios aplicados. De esta manera eldesarrollador con un click obtendrá nuevamente la visualización de los cambiossolicitados de manera automática.

38 5.4. Con�gurar los Estilos sobre los Formularios

Figure 5.19 Resultado de la variabilidad

5.4 Con�gurar los Estilos sobre los Formularios

Para lograr la con�guración de los estilos de los formularios se implementó unaintegración entre algunas funcionalidades que provee el editor en lo referente acon�guraciones de estilos (fuentes, colores y tamaños) y el modelo de formula-rios, con el �n de aplicar la con�guraciones de estilo realizadas y posteriormenterealizar la generación del archivo de estilos de la aplicación.

5.4.1 Con�guración de los Estilos sobre los Formularios

Para la ejecución de esta con�guración el editor XWT provee de manera nativauna vista de propiedades por cada componente que representan el formulario,entre estas propiedades de estilos se identi�caron las referentes a apariencia ytamaño, estas pueden ser con�guradas de la siguiente manera:

Figure 5.20 Resultado de la variabilidad

Para considerar la con�guración realizada por parte del desarrollador, el plu-gin de variabilidad descrito previamente considera adicionalmente el cargue delarchivo XWT con estilos, se realiza la identi�cación por cada componente de laspropiedades de estilo con�guradas y se actualiza de manera automática el modelode formularios según con�guración, posteriormente se continua con la nueva gen-eración del modelo XWT y �naliza con la transformación a texto del formulario

ViVaGUI 39

XWT para visualización de los cambios aplicados.Por otro lado, se genera de manera automática el archivo de estilos CSS

que se deberá usar en la aplicación, con el �n de considerar las con�guracionesrealizadas.

40 5.4. Con�gurar los Estilos sobre los Formularios

6Validación

En este capítulo presentamos la validación realizada sobre nuestro enfoque, conel �n evidenciar la mejora que nuestro proyecto hace a la productividad en laconstrucción de aplicaciones web, en el ámbito de la de�nición de modelos deformularios. El análisis consta de dos subsecciones, la primera presenta el caso deestudio realizado a nivel interno del proyecto y la segunda presenta la validaciónrealizada con el apoyo del grupo de Academia y las métricas obtenidas al haceruso del desarrollo realizado.

6.1 Caso de Estudio

Con el �n de explicar de manera más concreta esta propuesta, se presenta primeroun caso de estudio en donde se de�ne un problema especí�co relacionado conel desarrollo de una aplicación web. Una vez descrito este caso de estudio, seexplica la propuesta con un ejemplo concreto, para justi�car la manera en queeste enfoque soluciona las necesidades formuladas en las secciones previas.

El caso de estudio es una aplicación web para administrar los cursos de unadeterminada carrera que se ofrece en una universidad. Los requerimientos fun-cionales de la aplicación son los siguientes:

• Creación y actualización de las carreras ofrecidas por la universidad.

• Administración y asociación de los cursos que se ofrecen en cada carrera.

• Creación y actualización de las personas pertenecientes a la universidad.

• Asociación de cursos a estudiantes.

• Administración de las entidades básicas como los tipos de documento deidentidad.

El modelo de negocio del caso de estudio, tiene por entidad básica la cor-respondiente al TipoDocIdentidad. La entidad principal es Universidad la cualtiene un conjunto de elementos tipo Carrera para representar las carreras que

41

42 6.1. Caso de Estudio

ofrece. A su vez el elemento Carrera contiene un conjunto de elementos que rep-resentan los Cursos que esta abarca, también contiene un conjunto de elementosde tipo Estudiante que representan los alumnos. El elemento Curso es visto porun conjunto de Estudiantes y el Estudiante es una Persona que tiene un tipode documento de identidad asociado, representado con la relación a la entidadbásica TipoDocIdentidad.

Figure 6.1 Modelo de negocio

Por enmarcarse el contexto de este aporte en el ámbito de los formularios weby por el proyecto FORMS tener la capacidad de funcionar de manera integrada oindependiente al proyecto GENIUS, se procede a de�nir de manera independientea los modelos de negocio cada uno de los formularios que apoyarán esta aplicación,mediante el uso del proyecto FORMS. Se de�ne el siguiente modelo que representael contexto del caso de estudio:

Figure 6.2 Modelo de formularios

Validación 43

Con el �n de certi�car el funcionamiento de las herramientas ofrecidas por estatesis se toma la funcionalidad "Asociación de cursos a estudiantes" para haceruso de ellas. Se inicia con la visualización del modelo de formularios, se procedea realizar la con�guración de la variabilidad y se culmina con la con�guración deestilos.

6.1.1 Visualizar el Modelo de Formularios

El modelo de formularios de este caso de estudio se compone de una serie depantallas y se desea visualizar la que responde a la funcionalidad de asociar uncurso a un estudiante, llamada "Estudiante", mediante el uso de la herramientade visualización desarrollada se obtiene:

Figure 6.3 Visualización del formulario Asociación Curso a Estudiante

La pantalla número uno corresponde al resultado que se obtendrá después deejecución de actividades como la generación automática del código, integración

44 6.1. Caso de Estudio

en un proyecto web y despliegue en un navegador, la pantalla número dos muestrala visualización del modelo de formularios que se obtendrá usando la herramientadesarrollada por esta tesis, sin incurrir a las actividades mencionadas previa-mente.

6.1.2 Con�gurar la Variabilidad por Componente Grá�co

La con�guración de la variabilidad por componente grá�co se realiza sobre lavisualización obtenida previamente y esta es determinada por cada componentedel formulario, por ejemplo, se requiere cambiar la lista de cursos inscritos queproporciona la visualización de solo un campo, por una tabla, con el �n de vi-sualizar el campo del código del curso y el nombre del curso, adicionalmente sedesea que el semestre aparezca como un campo informativo y no como campopara ingresar, de la siguiente manera:

Figure 6.4 Con�guración de Variabilidad

Validación 45

6.1.3 Con�gurar los Estilos Sobre los Formularios

La con�guración de los estilos se realiza sobre la visualización del formulariosobre cada uno de los componentes, cuya �nalidad es captar la atención delusuario resaltando la información de mayor relevancia, por ejemplo, se requiereque la información del estudiante al ser una sección informativa se represente conuna tonalidad más sobria, resaltando los títulos y los nombres de los rótulos delos campos.

Por otro lado, al ser la sección de los cursos inscritos la sección con la queinteractuará el usuario, se requiere resaltar su relevancia, una propuesta para este�n sería:

Figure 6.5 Con�guración de Estilos

Los puntos previamente con�gurados (variabilidad y estilos) sobre la visual-ización del formulario, son actualizados en el modelo de formularios original parapreservar los cambios realizados al realizar la generación automática del códigoy despliegue de la aplicación.

Con estas actividades culmina el caso de estudio y se certi�ca el funcionamientode las herramientas generadas por esta tesis, adicionalmente el siguiente numeraldetalla las pruebas realizadas usando estas herramientas con otros formulariosdel proyecto Academia de la Universidad de los Andes.

6.2 Métricas de Validación

Para examinar la contribución propuesta por este trabajo, se realiza un primerejercicio usando como línea base de comparación los diversos formularios ac-tualmente generados por el proyecto Academia de la Universidad de los Andes,quienes usan de manera constante el proyecto FORMS para dar respuesta a re-querimientos de desarrollo.

Para reducir la complejidad del análisis presentada por las diferentes estruc-turas y niveles de di�cultad de los modelos de formularios, se realiza el estudiosegún la cantidad de componentes de los modelos de formularios que apoyan elsistema a desarrollar, y se utiliza la siguiente categorización según el nivel decomplejidad:

1. Baja: 1 � 15 componentes y 1 � 3 formularios

46 6.2. Métricas de Validación

2. Media: 16 � 26 componentes y 4 � 6 formularios

3. Alta: > 26 componentes y > 6 formularios

El proyecto Academia cuenta con la medición de una serie de criterios quepermiten evaluar el proceso de desarrollo. Para nuestro enfoque se utilizan es-tos mismos criterios y se realizan las mediciones pero usando la implementaciónrealizada en este proyecto.

Las actividades que hacen parte de las métricas de desarrollo del proyectoAcademia y son compatibles con este aporte, corresponden a cinco principales:

1. Crear el modelo de formularios: Es la de�nición del modelo de formulariosque apoyarán la aplicación, considerando cada uno de los formularios y loscomponentes requeridos.

2. Generar el código fuente: Tiempo en que se tarda las transformaciones demodelo a modelo y de modelo a texto en ejecutarse y generar el códigofuente del modelo de�nido.

3. Integrar el código fuente al proyecto web correspondiente: Es una de lasactividades más representativas del proceso de desarrollo, consiste en tomarel código fuente generado e integrarlo a la estructura de un proyecto web(nuevo o existente), adicionalmente incluye la actividad de implementar lasclases autogeneradas que pueden ser modi�cadas.

4. Visualizar y probar los formularios web: En esta actividad se puede visu-alizar lo generado y es dónde se identi�ca si es necesario realizar ajustes almodelo para generar los formularios que se desean.

5. Ajustar el modelo de formularios: Se realizan los ajustes al modelo deformularios para contemplar lo elementos faltantes o modi�car los de�nidospreviamente, con el �n de obtener los formularios deseados.

6. Iteraciones (Actividad No.2 � Actividad No.5): Cuando se ajusta el modelode formularios es necesario repetir las actividades de la dos a la cinco,la cantidad de veces necesarias hasta conseguir el formulario requerido,estas iteraciones según juicio de expertos del proyecto Academia se puedenagrupar basados en la complejidad del modelo, así:

6.1 Baja: 1 � 2 iteraciones

6.2 Media: 3 � 4 iteraciones

6.3 Alta: > 4 iteraciones

Para evaluar cada una de estas actividades y realizar la validación de la im-plementación, se toma una muestra de dos modelos de formularios del proyectoAcademia por cada grupo de complejidad de�nido (Alta, Media, Baja), es decir,se usan las herramientas ofrecidas por esta tesis sobre seis formularios difer-entes y se realiza una comparación entre los tiempos obtenidos con el uso de lasherramientas Vs. el tiempo previamente medido y entregado desde el proyectoAcademia.

Validación 47

Se midieron cada una de las actividades enumeradas previamente y se obtiene elsiguiente resultado:

Modelos de Complejidad Alta

Figure 6.6 Resultado validación modelos complejidad alta

Modelos de Complejidad Media

Figure 6.7 Resultado validación modelos complejidad media

Modelos de Complejidad Baja

Figure 6.8 Resultado validación modelos complejidad baja

Al realizar la medición de las actividades usando las herramientas de soporteprovistas por esta tesis y compararlas con las mediciones obtenidas por el proyectoAcademia, se identi�ca:

48 6.2. Métricas de Validación

1. Las actividades medidas se mantienen debido a que son actividades quesiempre se deben ejecutar por ser parte del proceso de desarrollo de softwarebasado en modelos.

2. El aporte de las herramientas de soporte provistas por esta tesis contribuyenprincipalmente a la disminución de iteraciones a ejecutar.

El análisis de estas mediciones arrojan una reducción en la cantidad de itera-ciones que se deben ejecutar, usamos como supuesto que se requerirá máximo unaiteración, debido a que la visualización de los formularios previa a la generacióndel código y la con�guración de la variabilidad contribuyen a la identi�cación yrealización de ajustes sobre los modelos de formularios y no es necesario incurrira más de una iteración para realizarlos. Adicionalmente se reduce el tiempo querespecta a visualización, ajustes y pruebas a los modelos de formularios, debidoa que se usan las herramientas de soporte provistas por nuestro enfoque.

Esta reducción corresponde aproximadamente a un promedio del cincuentapor ciento (50 % ) del tiempo normal utilizado para el proceso normal de de-sarrollo de los formularios de aplicación, incrementando la productividad en eldesarrollo de aplicaciones web basadas en modelos y reduciendo los costos de op-eración actuales al eliminar tareas manuales y realizarlas en forma automática.

Es de anotar que estos datos se presentan a manera de ilustración, no pre-tenden ser una prueba de�nitiva, debido a que fueron tomandos en un contextoparticular, sin embargo, los consideramos porque nos permiten evidenciar que sise presentaran mejoras en la productivadad del desarrollo, no es nuestra inten-sión presentar el porcentaje de aporte como un valor de�nitivo, se considera unaproximación en el contexto en que fueron medidos.

7Conclusiones y Trabajo Futuro

Nuestro enfoque tiene como propósito aumentar la productividad en el desarrollode software en el contexto del desarrollo web basado en modelos (MDWE), inte-gra nuevas funcionalidades que proporcionan al desarrollador de la aplicación unapoyo en las actividades a realizar para la de�nición y actualización de los mod-elos de formularios que soportan una solución, proporcionando una herramientainmersa en el ambiente de desarrollo de modelos que ofrezca la posibilidad deobtener una representación visual de cada uno de los formularios en el momentode su de�nición, sin necesidad de incurrir a actividades como la generación au-tomática del código, con�guración y despliegue de la aplicación para obtener esteresultado.

Adicionalmente ofrece la expresión de la con�guración de los componentesy elementos que hacen parte integral de un formulario, mediante la integraciónde una herramienta para el manejo de la variabilidad �na, la cual de manerainteractiva permite expresar y seleccionar por cada componente del formulariolos elementos compatibles que pueden ser con�gurados, presentando el resultadode esta con�guración de manera automática sobre la visualización del formulario.

Con el �n de aprovechar las funcionalidades nativas de un editor grá�co parala con�guración de estilos, tamaños, colores y fuentes, se hace uso de estas fun-cionalidades y se desarrolla la integración entre el editor visual XWT y el proyectoFORMS, con el �n de re�ejar las con�guraciones de estilos realizadas sobre lavisualización del formulario y ajustar el modelo de formularios para conservarlas.

7.1 Contribución

El ofrecer una alternativa de representación visual e interactiva de los modelosde formularios en el ambiente de desarrollo de modelos, permite al desarrolladorgrá�co la posibilidad de ver de manera anticipada la interfaz grá�ca que estáde�niendo y que obtendrá al ejecutar las actividades de generación del códigofuente, con�guración y despliegue de la aplicación, disminuyendo la probabilidadde ajustes manuales y evitando la re ejecución de la actividades previamentemencionadas, esto aporta al incremento de la productividad.

49

50 7.2. Trabajo Futuro

Al contar con la posibilidad de con�gurar la variabilidad �na en los compo-nentes grá�cos de los formularios de manera interactiva, se amplía la usabilidadde los modelos de formularios, debido a que no se requiere conocimiento en mod-elos y sus representaciones para lograr ajustarlos, aportando a la disminución deltiempo de aprendizaje para la manipulación de modelos de formularios.

Al realizar uso de funcionalidades nativas de un editor grá�co para la con-�guración de los estilos, fuentes, tamaños y colores, se aprovechan bondades deleditor que pueden ser re�ejadas en los modelos de formularios, cuya representa-ciones grá�cas en el editor son más representativas para el desarrollador de losformularios, que expresiones en sintaxis textuales como se realiza sobre los mod-elos. Haciendo uso de propiedades de los modelos de formularios de manera másfácil.

Esta propuesta es un primer acercamiento a la extensión de usabilidad de lasherramientas basadas en modelos para la de�nición y modi�cación de los modelosde formularios, este aporte permite la posibilidad de integrar los modelos coneditores visuales, logrando una representación y modi�cación interactiva de loscomponentes del modelo por parte de los desarrolladores de una aplicación.

7.2 Trabajo Futuro

Como trabajo futuro se evidencia la necesidad de ofrecer al desarrollador de losmodelos de formularios una manipulación de los mismos completamente grá�ca,sin considerar una primera de�nición del modelo de formularios mediante unasintaxis textual o estructura de árbol, para posteriormente obtener una repre-sentación visual de lo de�nido. Se propone ampliar el uso del editor visual conel �n de realizar la de�nición del formulario de manera grá�ca e interactiva ygenerar automáticamente el modelo de formularios que representa lo diagramadopor parte del desarrollador.

Con este aporte surge la necesidad de hacer uso de estas herramientas enotras propuestas basadas en modelos, se puede realizar una extensión del proyectoFORMS para considerar un grupo más robusto de componentes a representar,con el �n de disminuir la probabilidad que otras iniciativas consideren elementosdiferentes y se deban realizar ajustes adicionales al desarrollo. Adicionalmente alhacer esta extensión se obtiene una serie más amplia de componentes y se podránofrecer al desarrollador más posibilidades de variabilidad.

Por otro lado, se propone la extensión del proyecto FORMS para contemplarlas propiedades que permitan manejar un esquema de distribución de los compo-nentes en el formulario, ofreciendo la alternativa de de�nir o contar con plantillasde distribución de elementos a ser visualizadas por parte del editor visual y serrepresentadas a nivel de modelos.

Bibliografía

[1 ] R. France y B. Rumpe, "Model-driven development of complex software:A research roadmap," Future of Software Engineering, pp. 37-54, 2007.

[2 ] J. Bézivin, "In Search of a Basic Principle for Model Driven Engineering,"European Journal for the Informatics Professional, vol. V, pp. 21-24, 2004.

[3 ] Nathalie Moreno, José R. Romero, and Antonio Vallecillo, An overviewof model-driven web engineering and the mda, 2008, pp. 353-382.

[4 ] R. C. Willy Montes, GENIUS: Use Case Pattern-Based Approach To WebUser Interface Generation For Enterprise Applications, 2011.

[5 ] Meta-Object Facility (MOF) 1.4 Speci�cation. Object Management Group,Inc. April 2002.

[6 ] The Eclipse Foundation, "Swing/SWT" [En línea]. Disponible:

http://www.eclipse.org/articles/article.php?�le=Article-Swing-SWT Inte-gration. [último acceso: 06 2012].

[7 ] N. Koch, A. Knapp, G. Zhang y H. Baumeister, "UML-based Web Engi-neering: An Approach based on Standards," Web Engineering: Modellingand Implementing Web Applications, pp. 157-191, 1999.

[8 ] A. Fatolahi, S. Some y T. Lethbridge, "Towards a Semi-Automated Model-Driven Method for the Generation of Web-base Applications from Use-cases," MDWE 2008, 2008.

[9 ] F. Ceballos, H. Arboleda y R. Casallas, "Un Enfoque para DesarrollarAplicaciones WEB Basado en Líneas de Producto Dirigidas por Modelos,"Paradigma, 2009.

[10 ] "Google Web Toolkit - Google Code," [En línea]. Disponible:

http://code.google.com/webtoolkit/. [último acceso: 06 2012].

[11 ] The Eclipse Foundation, "Window Builder" [En línea]. Disponible:

www.eclipse.org/windowbuilder. [último acceso: 03 2012].

[12 ] SwiXml, [En línea]. Disponible: www.swixml.org. [último acceso: 032012].

[13 ] RedView, [En línea]. Disponible: redview.org. [último acceso: 03 2012].

[14 ] The Eclipse Foundation, "XWT" [En línea]. Disponible:

http://wiki.eclipse.org/E4/XWT. [último acceso: 06 2012].

51

52

[15 ] H. Arboleda, R. Cassallas. FieSta: An approach for Fine-Grained ScopeDe�nition, Con�guration and Derivation of Model-Driven Software ProductLines, 2009.

[16 ] Krzysztof Czarnecki and Michal Antkiewicz. Mapping features to models:A template approach based on superimposed variants. In Robert Gl�ckand Michael R. Lowry, editors, GPCE, volume 3676 of Lecture Notes inComputer Science, pages 422-437. Springer, 2005.

vivagui: visualización y manejo de variabilidad en modelos

Documents