Generación de código de capa Web a partir de diagramas de estado extendidos

Texto completo

(1)GENERACIÓN DE CÓDIGO DE CAPA WEB A PARTIR DE DIAGRAMAS DE ESTADO EXTENDIDOS. JOHNATAN ANDRÉS ROJAS TOVAR TATIANA HERNÁNDEZ MARTÍNEZ. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS BOGOTÁ D. C., 2008.

(2) GENERACIÓN DE CÓDIGO DE CAPA WEB A PARTIR DE DIAGRAMAS DE ESTADO EXTENDIDOS. JOHNATAN ANDRÉS ROJAS TOVAR TATIANA HERNÁNDEZ MARTÍNEZ. Proyecto de Grado. Director Nicolás López. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS BOGOTÁ D. C., 2008.

(3) Nota de aceptación. Director de Proyecto. Jurado. Jurado. Bogotá D.C. Mayo de 2008.

(4) TABLA DE CONTENIDO 1.. INTRODUCCIÓN .................................................................................................... 6. 2.. OBJETIVOS............................................................................................................... 7. 3.. 2.1.. OBJETIVO GENERAL ........................................................................................ 7. 2.2.. OBJETIVOS ESPECÍFICOS ................................................................................. 7. CONTEXTO .............................................................................................................. 8 3.1. TESIS PARA DEFINIR UN FRAMEWORK DE DESARROLLO MDA (Yie Garzón, 2006) ................................................................................................................. 8 3.2.. TESIS CHANGESET MDA (Álvarez, y otros, 2007) .......................................... 8. 3.3.. TESIS WEB MDA (Pineda Soto, y otros, 2007) ................................................... 9. 3.4.. TRABAJO DE JUAN SEBASTIAN MONTAÑA (Montaña, 2008) ..................... 9. 3.5.. DIAGRAMAS DE ESTADO EXTENDIDOS .................................................... 10. 4.. DETALLE DE PROPUESTA .................................................................................. 11. 5.. METAMODELOS ................................................................................................... 12. 6.. 7.. 5.1.. METAMODELO DE MAQUINA DE ESTADOS EXTENDIDA ...................... 12. 5.2.. METAMODELO DE ESQUEMAS DE PRESENTACIÓN ................................ 13. 5.3.. METAMODELO DE ENTRETEJIDO ............................................................... 13. 5.4.. METAMODELO DE ENTRETEJIDO RESULTADO ........................................ 14. TRANSFORMACIONES........................................................................................ 15 6.1.. TRANSFORMACIONES MODELO A MODELO ........................................... 15. 6.2.. TRANSFORMACIÓN MODELO A CÓDIGO ................................................. 15. TRABAJO FUTURO ............................................................................................... 16 7.1.. ACTUALES LIMITACIONES RESPECTO A LOS OBJETIVOS....................... 16. 7.2.. CONSIDERACIONES PARA EXTENSIONES ................................................. 16. 7.3.. TRABAJO FUTURO A LARGO PLAZO .......................................................... 16. 8.. CONCLUSIONES ................................................................................................... 17. 9.. BIBLIOGRAFÍA ...................................................................................................... 17 iv.

(5) 10.. ANEXOS .............................................................................................................. 18. 10.1.. DETALLE DE TRANSFORMACIONES ....................................................... 18. 10.1.1.. Helpers de Transformación de Moldeo a Modelo .................................... 18. 10.1.2.. Reglas de transformación de Modelo a Modelo ....................................... 19. 10.1.3.. Transformación Modelo a Código ............................................................ 20. 10.2.. MANUAL DE GENERACIÓN DE CÓDIGO ............................................... 21. 10.2.1.. PRERREQUISITOS .................................................................................... 21. 10.2.2.. AMBIENTE DE DESARROLLO................................................................ 22. 10.2.3.. INSTRUCCIONES PARA GENERACIÓN DE CÓDIGO ......................... 22. v.

(6) 1. INTRODUCCIÓN El desafío al cual se enfrentan las casas de software en la actualidad va más allá de la elaboración de las aplicaciones, el desarrollo de las mismas con un adecuado nivel de calidad contando con recursos de tiempo cada vez más cortos puede representar su sostenimiento en el actual mercado y puede llegar a ser un factor de diferenciación. Sin embargo, es común encontrar que el desarrollo de diferentes aplicaciones tiene muchos aspectos en común en su proceso, diseño y desarrollo, por lo que es razonable pensar qué parte del tiempo es invertido en tareas que son repetitivas tanto en ejecución como en resultado. Por lo tanto, se podría llegar a pensar que se puede aumentar la productividad si se reemplazan por un número menor de tareas, o por tareas menos costosas en recursos de personal, tiempo y dinero, de tal forma que se pueda automatizar parte del trabajo que se realiza. De esta forma se pueden encontrar algunas de las propuestas más novedosas que atacan los problemas mencionados con anterioridad, la primera propone la generación de código con Fábricas de Software con una o más líneas de producción SPL (Software Product Line); la segunda permite modelar un grupo de aplicaciones a partir de la definición de elementos comunes entre las mismas MDA (Model Driven Architecture). La utilización de la segunda en la primera cuenta con herramientas de algunos grupos académicos como los formados por Eclipse.org. El propósito de esta tesis es realizar un primer acercamiento al soporte del desarrollo de código de capa web enfocándose en la navegación y con el uso de las herramientas mencionadas, de forma tal que se propone a partir de diagramas de estado extendidos o diagramas de navegación generar el código de capa web.. 6.

(7) 2. OBJETIVOS 2.1. OBJETIVO GENERAL Construir bajo el enfoque MDA artefactos que permitan la generación de código a partir de modelos de máquinas de estado que representen los aspectos de navegación.. 2.2. OBJETIVOS ESPECÍFICOS Definir un metamodelo de interacción que permita representar las diferentes formas en las cuales puede ser representado un elemento y por lo tanto las cuales representan la interacción con el usuario. Definir un metamodelo de navegación extendido por representación de máquinas de estado estilo changeset que defina tanto las páginas de un caso de uso como las propiedades de elementos visibles. Definir un metamodelo de lenguaje que sea el resultado de entretejer los metamodelos anteriores para que a partir de éste se genere el código de capa Web. Definir las transformaciones necesarias entre el metamodelo de interacción y navegación para refinar modelos conformes a ese metamodelo hacia un modelo de lenguaje y luego generar el código resultado. Probar los metamodelos y transformaciones a partir de un pequeño ejemplo.. 7.

(8) 3. CONTEXTO La Universidad de los Andes en el Departamento de Ingeniería de Sistemas y Computación con su grupo de investigación Qualdev (Quality Software Development) se encuentra desarrollando muchos proyectos que utilizan el enfoque MDA para la construcción de sus aplicaciones. Entre los proyectos con mayor antigüedad y sobre los cuales este trabajo se fundamentará se encuentran CHANGESET MDA y WEB MDA. Los siguientes proyectos se basan en la aplicación insignia de Qualdev: CHANGESET. Según el grupo de investigación, “Changeset es un sistema de administración de configuración de alto nivel. El propósito es proveer una aplicación que permita a los usuarios un manejo más amigable de sus productos, ya sea mediante su versionamiento, su agrupación en líneas de base versionable o el seguimiento de su desarrollo y estado mediante solicitudes de cambio.”1. 3.1. TESIS PARA DEFINIR UN FRAMEWORK DE DESARROLLO MDA (Yie Garzón, 2006) Este trabajo fue el primer acercamiento al desarrollo orientado a MDA cuyo principal resultado fue la especificación del Framework de trabajo para desarrollo de aplicaciones que se especializan en las operaciones CRUD. Las especificaciones de dicha tesis muestran tanto el estado del arte para ese momento como los lineamientos propuestos por la OMG para el desarrollo basado en MDA y la especificación para aplicaciones de manejo de información; además, propone el grupo de herramientas que componen este framework: Eclipse, EMF, Omondo, ATL y Acceleo.. 3.2. TESIS CHANGESET MDA (Álvarez, y otros, 2007) Este trabajo se fundamentó en la tesis anterior colocando como proyecto de prueba la aplicación Changeset. Como resultado se logró generar la base del proyecto el cual comprende la creación de entidades, definición de atributos, adición de servicios CRUD y generación de objetos de persistencia de las entidades en base de datos. Para más información acerca de la aplicación y su actual desarrollo consultar en la página http://qualdev.uniandes.edu.co/wikiDev/doku.php?id=development:projects:changes et:changeset/. 1. 8.

(9) Por lo tanto con éste trabajo se puede generar código de capa de persistencia para aplicaciones web.. 3.3. TESIS WEB MDA (Pineda Soto, y otros, 2007) Este trabajo extendió la funcionalidad del anterior al ser un primer acercamiento a la generación de código de capa Web. Como resultado, a partir de las definiciones de las entidades de negocio se obtenía el código de capa Web que permitía realizar las operaciones CRUD sobre cada entidad de negocio definida. Su metodología incluyó tanto la definición de metamodelos por cada capa bajo los lineamientos de la tesis (Yie Garzón, 2006) como la propuesta de diferentes plantillas de desarrollo para la generación final de código.. 3.4. TRABAJO DE JUAN SEBASTIAN MONTAÑA (Montaña, 2008) El actual trabajo que se encuentra desarrollando Juan Sebastián Montaña es otro enfoque para desarrollar el código de capa Web el cual toma en cuenta las diferentes formas posibles de navegación de acuerdo a los requerimientos funcionales de una aplicación. Su trabajo plantea la generación de código de capa Web a partir de las entidades de negocio obtenidas con ChangesetMDA. Para lograr divide la generación de código en tres niveles de composición de modelos conformes a 5 metamodelos.. Ilustración 1 Propuesta Tesis de Juan Sebastián Montaña. El metamodelo de Negocio representa las entidades de negocio y las relaciones existentes entre ellas. El metamodelo de Navegación se basa en los diagramas UML 2.0 de máquina de estados que puede representar por cada caso de uso la secuencia entre páginas y estados de procesamiento. Cuando se entretejen2 los Entiéndase este término “entretejido” como la composición de dos o más modelos para obtener un modelo resultante.. 2. 9.

(10) modelos de negocio y navegación se genera un modelo de Arquitectura, que representa un modelo de navegación con las extensiones que consideran las entidades de negocio y las relaciones entre ellas; por lo tanto, lo que se esperaría del diagrama de arquitectura es un diagrama de Estado Extendido (ver sección 3.5) por cada diagrama de caso de uso definido en navegación. El modelo de Presentación representa las posibles formas en que puede ser representada una entidad visible. Por último, en entretejido de los modelos de Arquitectura e Interacción generan el modelo de Lenguaje que representa una máquina de estados extendida con la información suficiente para generar código de capa Web.. 3.5. DIAGRAMAS DE ESTADO EXTENDIDOS. Los diagramas de estado extendidos representan la navegación a partir de máquinas de estado con extensiones y restricciones. Es caracterizado por: a. Estado de Interacción Un estado de interacción es definido como una página Web que tiene elementos visibles o campos con los cuales interactuará el usuario. b. Estado de Procesamiento Un estado de procesamiento es definido como un estado que procesa alguna entrada y recibe como entrada los datos de otro estado de interacción con el usuario. c. Elemento Visible Corresponde a la representación de elementos visuales de algún tipo con el que interactuará el usuario. d. Transición La transición corresponde a un cambio de un estado como respuesta a una acción. Si el origen es un estado de interacción con elementos 10.

(11) visibles la transición debe ser nombrada <nombre del bean>.<nombre de la acción>, asumiendo que las entradas del método son los elementos visibles del estado anterior. Para el otro caso, si el origen es un estado de procesamiento la respuesta es el resultado de la ejecución de alguna acción (success, error,…). Para el caso de Estados de Interacción, éstos definen qué tipo de entidades visibles están asociados a éste, entendiéndolas como aquellas que tomarán o mostrarán información dinámica al usuario.. 4. DETALLE DE PROPUESTA El actual trabajo representa una parte del desarrollo de la propuesta de Juan Sebastián Montaña (Montaña, 2008), el cual genera código a partir de los diagramas de estado obtenidos con los lineamientos del metamodelo de Arquitectura.. Ilustración 2 Propuesta de Tesis. El metamodelo de Navegación Extendido, el cual corresponde a una extensión del metamodelo de navegación de (Montaña, 2008), define modelos de diagramas de estado extendidos y el metamodelo de Presentación y Lenguaje tienen el mismo propósito que en la propuesta de Montaña. El modelo de Presentación contiene las opciones por la cuales una entidad puede ser mostrada al usuario, éstas tomadas de la especificación genérica de JSF. Por cada caso de uso se definen tanto el diagrama de navegación-extendido, como el tipo de presentación que tendrá cada elemento visible a partir del entretejido de modelos. De esta forma se genera el modelo de lenguaje a partir del cual se generará el código de capa Web. Para realizar de forma más sencilla la creación de modelos de diagramas de estado se utilizó GMF (Graphical Modeling Framework), con el cual se genera un plugin de Eclipse, éste permite definir gráficamente los modelos y asegura que se restrinjan al metamodelo de origen. 11.

(12) Para el entretejido fueron utilizados tanto AMW como ATL: el primero permite definir relaciones entre modelos o links, de esta forma se vinculan elementos visibles con elementos Web que pueden ser desplegados en una página; el segundo, permite realizar transformaciones tal que los links definidos con la primera herramienta puedan ser utilizados para generar un modelo resultante con la información tanto de estados y transiciones como de elementos Web. Por último, utilizamos las transformaciones de modelo a código a partir de plantillas, éstas fueron definidas para el estándar JSF que se encuentra representado en el modelo schemeJSF, de esta forma definimos generación de código.. 5. METAMODELOS 5.1. METAMODELO DE MAQUINA DE ESTADOS EXTENDIDA La máquina de estados extendida representa los elementos de navegación específicos para un caso de uso, éste se encuentra representado en la siguiente figura:. 12.

(13) Las entidades de mayor relevancia son: StateChart: Contiene toda la definición de un caso de uso. Inicial State: Estado que representa el inicio del caso de uso. Final State: Estado final que representa el fin del caso de uso. Interaction State: Estado de interacción que representa una página Web con la cual interactúa el usuario. VisibleElement: Elemento que pertenece a un estado de interacción y el cual es visible al usuario. ProcessingState: Es el estado en que se procesan las variables ingresadas en un proceso de Interacción anterior. Transition: Representa el cambio de un estado a otro a través de una acción cuyo nombre corresponde al de la transición. 5.2. METAMODELO DE ESQUEMAS DE PRESENTACIÓN. Secheme: Contenedor de elementos web de un lenguaje. Web Element: Componente definido para un estándar de lenguaje de página Web. 5.3. METAMODELO DE ENTRETEJIDO. 13.

(14) La descripción completa se encuentra en la Wiki del grupo AMW de Eclipse. 5.4. METAMODELO DE ENTRETEJIDO RESULTADO. 14.

(15) El metamodelo resultante es similar al de máquinas de estado, con la diferencia que fue enriquecido con la especificación dada por los elementos Web definidos en el estándar, éste es utilizado para definir el modelo resultante del entretejido, fue definido para propósitos de éste proyecto. InteractionState: este estado ahora cuenta con el nombre del backingbean y el nombre del método que procesará las entradas. VisibleElement: el estado visible ahora contiene el nombre del WebType especificado por el entretejido de un elemento del esquema y este elemento.. 6. TRANSFORMACIONES 6.1. TRANSFORMACIONES MODELO A MODELO Las transformaciones de modelo a modelo son utilizadas para a partir de uno o más modelos de entrada obtener uno o más de salida, éstas se realizan conforme a metamodelos para cada entrada tal que se definen reglas de estructura de los mismos. Estas transformaciones fueron utilizadas en este proyecto para lograr definir el entretejido entre los modelos de Navegación-extendido y presentación; para lograr esto definimos reglas de transformación por cada componente del modelo de entrada de navegación y junto con helpers3 que permiten obtener los links definidos por el modelo de entretejido y de estos la información necesaria del modelo de Esquema para obtener el modelo resultante. En la sección de anexos puede encontrar el detalle de las transformaciones utilizadas y los helpers. 6.2. TRANSFORMACIÓN MODELO A CÓDIGO Las transformaciones de modelo a código permiten que a partir del conocimiento del metamodelo, por ende la estructura de sus modelos, generar código en algún lenguaje. Para el caso de éste proyecto fue utilizado como lenguaje JSF y para conocer las posibles estructuras se limita al estándar; de esta forma Para conocer más acerca de la sintaxis y funcionamiento de las transformaciones ALT diríjase al HOME de ATL group que se encuentra en la Bibliografía.. 3. 15.

(16) definimos plantillas de transformación para generar las páginas web, los backing beans y los archivos *.xml. En la sección de anexos puede encontrar el detalle de las transformaciones utilizadas en las plantillas.. 7. TRABAJO FUTURO 7.1. ACTUALES LIMITACIONES RESPECTO A LOS OBJETIVOS La generación de código de capa web de momento se encuentra restringida por: • En la definición de los diagramas de estado extendidos solo puede haber una transición de salida para un estado de interacción a un bean. • La secuencia de eventos debe comenzar con un estado de interacción y luego uno de procesamiento, no puede haber dos o más estados de interacción seguidos. • La etiqueta con la que se identifica el elemento visible en la página corresponde al nombre del mismo. • No se encuentra soportado UIOutput y UIImage. • La generación de momento no utiliza hojas de estilo css u otras tecnologías web más avanzadas para el cambio de imágenes.. 7.2. CONSIDERACIONES PARA EXTENSIONES Desde el modelo existe la posibilidad de realizar operaciones CRUD para así eventualmente generar la definición de elementos visibles a partir de éstos. Además es importante tener en cuenta que en caso de querer extender el actual estándar JSF se deben modificar los modelos de esquema, entretejido y plantillas.. 7.3. TRABAJO FUTURO A LARGO PLAZO • • • • • •. Poder asociar un elemento visible a un webBean específico. Asociar los modelos de navegación con el modelo el mundo para automatizar los formularios Web de operaciones CRUD. Modelar el include de páginas JSP en un estado de interacción. Modelas las dependencias de casos de uso en formato de modelos de navegación. Asociar la arquitectura del negocio al código de capa web. Extender la generación a un servidor de aplicaciones adicional a jboss. 16.

(17) 8. CONCLUSIONES •. •. •. Hasta este punto se puede generar código de capa web de diagramas de estado extendidos siempre y cuando se encuentren bajo consideraciones de las actuales limitaciones. Se puede decir que el aporte de esta tesis fue una primera aproximación a la construcción de un artefacto MDA que genera código de capa web que considerara las posibles variaciones en la navegación. Otro aporte fue para la navegación web la adición de herramientas como GMF para facilitar la definición de modelos y AMW para modificar las opciones de presentación. De esta manera se aporta al trabajo de (Montaña, 2008) en el sentido que apoya la generación de código y el entretejido del segundo nivel.. 9. BIBLIOGRAFÍA Álvarez, Juan Carlos, Hoyos, Nicolás y Leaño, Rafael Andrés. 2007. ChangesetMDA. Aplicaciones MDA (Model-Driven Architecture) para el desarrollo de aplicaciones. Bogotá D. C. : s.n., 27 de mayo de 2007. Montaña, Juan Sebastian. 2008. WARL: Web Applications Refinement Line. 2008. Pineda Soto, Luis Alberto y Zucchet Amaya, Jean Philip. 2007. Web MDA: Generación código capa Web bajo el enfoque MDA. Bogotá D. C. : s.n., 2007. Yie Garzón, Andrés. 2006. Framework de MDA para aplicaciones empresariales hacia plataformas JEE5 y .NET – Transformaciones. Bogotá D. C. : s.n., 2006. Acceleo Home. http://www.acceleo.org/, última visita 18 de junio de 2008. ALT Eclipse Home. http://www.eclipse.org/m2m/atl/, última visita 18 de junio de 2008. AM3 Home. http://wiki.eclipse.org/index.php/AM3_Ant_Tasks, última visita 18 de junio de 2008. Eclipse Modeling Framework Home. http://www.eclipse.org/modeling/emf/, última visita 18 de junio de 2008.. 17.

(18) Java Server Faces Home. http://java.sun.com/javaee/javaserverfaces/, última visita 18 de junio de 2008. Atlas model weaver Home. http://www.eclipse.org/gmt/amw/, última visita 18 de junio de 2008.. 10. ANEXOS 10.1. DETALLE DE TRANSFORMACIONES 10.1.1. Helpers de Transformación de Moldeo a Modelo Nombre del Helper getWebElement() Descripción Devuelve un elemento de tipo WebElement el cual corresponde al señalado por un link.. Nombre del Helper Descripción. getMyLinksSequence() Devuelve una secuencia de links que apuntan a un elemento visible con el nombre del que llama al helper.. Nombre del Helper. isMyVisibleElement (v:VisibleElement) Verifica que un link corresponda al elemento visible correcto.. Descripción. Nombre del Helper Descripción. getMyLink() Retorna el elemento visible correspondiente al elemento visible que llamó al helper.. Nombre del Helper Descripción. getMyTransition() Retorna la transición que tiene como fuente (source) al estado de interacción que llama al helper. 18.

(19) 10.1.2. Reglas de transformación de Modelo a Modelo Archivo de Transformación: Metamodelos de Entrada: • MM de Maquinas de Estado (stateChartsVisible.ecore) • MM de Esquema de Visualización Web (visualizationScheme.ecore) • MM de entretejido (base_extesion.ecore) Metamodelo de Salida: MM de Maquinas de Estado Resultante (stateChartsVisibleOutput.ecore) Nombre de Regla Descripción. StateChart2StateChart Transforma State Chart conservando el mismo valor de atributos que la máquina de estado de origen.. Nombre de Regla Descripción. InitialState2InitialState Transforma el estado inicial conservando el mismo valor de atributos que el estado inicial de origen.. Nombre de Regla Descripción. FinalState2FinalState Transforma el estado final conservando el mismo valor de atributos que el estado final de origen.. Nombre de Regla Descripción. ProcessingState2ProcessingState Transforma el estado de procesamiento conservando el mismo valor de atributos que el estado de procesamiento de origen.. 19.

(20) Nombre de Regla Descripción. Transition2Transition Transforma la transición de estado conservando el mismo valor de atributos que la transición de origen.. Nombre de Regla Descripción. VisibleElement2VisibleElement Transforma el elemento visible conservando el mismo valor de atributos que la transición de origen, y adicionando el tipo de elemento web que corresponde al enlace definido en el entretejido.. Nombre de Regla Descripción. InteractionState2InteractionState Transforma el elemento visible conservando el mismo valor de atributos que la transición de origen, y adicionando el nombre del bean al cual procesa los datos de este estado de Interacción, si es que existe este.. 10.1.3. Transformación Modelo a Código Archivo de Transformación FacesTemplate.mt Elemento de entrada <nombre del modelo resultante>.xmi Elemento generado faces-config.xml Descripción Genera el archivo que describe la navegación entre páginas web de acuerdo a las transiciones definidas en el modelo de entrada.. Archivo de Transformación Elemento de entrada. WebBeanTemplate.mt <nombre del modelo resultante>.xmi 20.

(21) Elemento generado Descripción. <nombre del backingbean>.java Genera los beans de procesamiento descritos en la navegación del caso de uso.. Archivo de Transformación Elemento de entrada Elemento generado Descripción. WebInteractionJSF.mt <nombre del modelo resultante>.xmi <nombre del estado.jsp> Genera las páginas jsp que son representadas por los estados de interacción del caso de uso.. Archivo de Transformación Elemento de entrada Elemento generado Descripción. buildwar.mt <nombre del modelo resultante>.xmi build.xml Genera un archivo build ant para el empaquetamiento automático y generación del archivo .war al cual se le hará deploy en el servidor.. Archivo de Transformación Elemento de entrada Elemento generado Descripción. webxml.mt <nombre del modelo resultante>.xmi web.xml Genera el archivo que especifica los parámetros para la aplicación JSF, mapea el nombre del servlet y el mapeo jsf a un nombre simbólico.. 10.2. MANUAL DE GENERACIÓN DE CÓDIGO 10.2.1. PRERREQUISITOS Es necesario estar familiarizado con los textos del contexto definido al principio de este documento además de las herramientas del ambiente de desarrollo.. 21.

(22) 10.2.2. AMBIENTE DE DESARROLLO Es necesario tener un eclipse completamente configurado, para el momento del desarrollo se utilizó la siguiente configuración para la máquina virtual de java 1.6: • Eclipse 3.3.1 • EMF 2.1.1 • ATL 2.0 • AM3 Descargue del repositorio CVS4 el proyecto WebInteractionGenerator y el código del plugin del proyecto WebInteractionVisibleElements. 10.2.3. INSTRUCCIONES PARA GENERACIÓN DE CÓDIGO i. Generación de código de plugin: Abra el archivo WebInteractionVisibleElements/metamodel/ stateChartsVisible.genmodel y genere el código del editor.. Debe comunicarse con el grupo Qualdev para solicitar acceso, diríjase a la página http://qualdev.uniandes.edu.co/mainWiki/doku.php y consulte si le es permitido obtener el código de éste proyecto. 4. 22.

(23) Ésta ejecución generará los proyectos WebInteractionVisibleElements.edit y WebInteractionVisibleElements.editor dentro del workspace. Después genere el código para los diagramas con el archivo WebInteractionVisibleElements/metamodel/ stateChartsVisible.gmfgen. Una vez generados los tres proyectos ejecute cualquiera de ellos como aplicación Eclipse.. 23.

(24) 24.

(25) ii. Creación del modelo de caso de uso. Con la utilidad del plugin del ambiente de ejecución puede crearse en un ambiente gráfico modelos de máquinas de estado extendidos. Es necesario primero que todo crear un proyecto y dentro de éste crear los diagramas de estado por cada caso de uso.. Una vez creado el proyecto se creará un nuevo modelo StateChartsVisible, se recomienda conservar durante la creación el nombre por defecto del nuevo archivo. Una vez definido el nombre del diagrama se creará un archivo .stateChartVisible el cual corresponde al modelo del caso de uso, el otro archivo stateChartsVisible_diagram es el archivo que contiene la visualización del modelo. El archivo sobre el que se trabajará será el. 25.

(26) segundo, utilizando los utilitarios de la paleta (Palette) se pueden crear los diferentes componentes del diagrama de navegación. 5 La creación de elementos visibles solo es permitida para los estados de interacción, y a éstos se les define el tipo de acuerdo al estándar JSF.. Además de los estados es necesario definir las transiciones entre éstos, las cuales tienen características distintas dependiendo del tipo de estado de origen.. De momento la utilidad de definición de estados que corresponden a operaciones CRUD se encuentra deshabilitada, es necesario por cada estado de interacción aclarar que la operación CRUD realizada en ella es de tipo “none”.. 5. 26.

(27) Cuando el estado de origen es de interacción es necesario definir el nombre de la transacción como <nombre del bean>.<nombre acción>. De otro lado, si proviene de un estado de procesamiento el nombre de la transacción definirá el de las posibles respuestas del Bean (success, error,…), siendo solo una por cada transición. Es importante una vez terminado toda la definición guardar el diagrama para que el archivo del modelo se actualice. iii.. Creación del modelo de entretejido.. 27.

(28) Utilice el wizard de Weaving para la creación del modelo de entretejido6 utilizando como modelo base mw_base_extension.km3. El modelo de la izquierda debe corresponder al modelo de navegación de caso de uso y el modelo de la derecha al esquema definido para elementos JSF.. Es importante para la generación que cada uno de los elementos Visibles esté definido por un link y corresponda a un elemento del modelo de Presentación, se puede comprobar la correspondencia correcta entre UIComponent en la vista de propiedades. En la vista de propiedades puede observar si el atributo Component del elemento visible corresponde al atributo Type Option de Scheme para realizar correctamente el entretejido. iv. Ejecutar transformación modelo a modelo Dentro de la carpeta atl se encuentra la transformación que realizará el entretejido, para ejecutarla para este caso de uso modifique el archivo stateMachine2stateMachineJSF.launch realizando los pasos de la siguiente figura. Los pasos específicos de utilización del wizard se encuentran en http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt/AMW/org.eclipse.weaver .doc.user/index.html 6. 28.

(29) Dentro de esta configuración debe redefinir los modelos de entrada useCase que corresponde al caso de uso, weaving que corresponde al modelo de entretejido y out que corresponde al modelo de salida. Luego se ejecuta con el botón Run.. 29.

(30) v. Creación del proyecto de código destino Cree dentro del workspace el proyecto que corresponderá al proyecto destino donde estará el código de capa Web7, éste debe contener las siguientes carpetas: src, deploy, public_html, lib. Dentro de la última deben estar las librerías necesarias para aplicaciones JSF8 y definidas en el buildpath del proyecto. vi. Ejecución de transformación modelo a código Debe editar el archivo jsf.chain que se encuentra dentro de la carpeta generator. Dentro de éste se encuentran las carpetas y proyecto destino. Una vez editado realice la acción Launch para ese chain. Note que solo esas tres carpetas deben ser editadas sin afectar el funcionamiento.. 7 8. Éste por defecto es WebInteraction.Generated Para el caso podrían ser myfaces, tomahawk, …. 30.

(31) Finalmente el proyecto generado tendrá los archivos faces-config.xml, web.xml, las páginas *.jsp por cada estado y los backing beans dentro del source (src).. 31.

(32) vii. Ejecución de código en el Servidor de Aplicaciones. De los archivos generados se encuentra el ANT build.xml, el cual al ser ejecutado genera el archivo *.war dentro de la carpeta deploy, el cual debe ser copiado en SERVER_HOME9/server/default/deploy/. Para el ejemplo generado anteriormente las páginas generadas serían mostradas en las siguientes figuras:. El código de los beans corresponderá a los métodos vacíos que siempre retornan “success”, en comentarios se encontrará las otras opciones de retorno para el backing bean ya configuradas en el archivo facesconfig.xml.. 9. Entiéndase SERVER_HOME como la ubicación en disco del servidor de aplicaciones.. 32.

(33) 33.

(34)