Prototipo de herramienta para el desarrollo de aplicaciones web basadas en MeDAW. (metodología para el desarrollo de aplicaciones web)

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR Ingeniería de Computación Prototipo de herramienta para el desarrollo de aplicaciones web basadas en MeDAW (metodología para el desarrollo de aplicaciones web) Por Ricardo Enrique Blanch Machado Proyecto de Grado Presentado ante la Ilustre Universidad Simón Bóĺıvar como Requisito Parcial para optar al Título de Ingeniero de Computación Sartenejas, Octubre de 2007

2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE COMPUTACIÓN ACTA FINAL DEL PROYECTO DE GRADO Prototipo de herramienta para el desarrollo de aplicaciones web basadas en MeDAW (metodología para el desarrollo de aplicaciones web) Presentado por Ricardo Enrique Blanch Machado Este Proyecto de Grado ha sido aprobado por el siguiente jurado examinador: Prof. Ascánder Suárez Prof. Gabi Escuela Prof. Yudith Cardinale Sartenejas, Octubre de 2007 ii

3 Prototipo de herramienta para el desarrollo de aplicaciones web basadas en MeDAW (metodología para el desarrollo de aplicaciones web) por Ricardo Enrique Blanch Machado RESUMEN Actualmente, una gran cantidad del software desarrollado a nivel mundial se ejecuta en ambientes web. El diseño de estas aplicaciones requiere del conocimiento de una gran variedad de tecnologías. Existen frameworks o ambientes de trabajo que permiten facilitar un poco la tarea de desarrollar una aplicación web. En el caso de aplicaciones web basadas en Java se puede utilizar el ambiente de trabajo Struts basado en el patrón de diseño MVC (Model - View - Controller). Desafortunadamente, existen algunas tareas en Struts que no son tan fáciles de realizar, aun cuando se tiene un diseño previo de la aplicación, como es la configuración del controlador que implica frecuentemente la edición de un archivo XML de sintaxis complicada. Las metodologías tradicionales para desarrollar software tampoco se adaptan muy bien a las necesidades de los proyectos de desarrollo, ya que no incluyen elementos presentes en la creación de aplicaciones hipermedia. Tomar estos dos aspectos por separado generalmente no basta para obtener un buen resultado. Para desarrollar aplicaciones web basadas en Struts es mejor utilizar una metodología que se adapte al patrón MVC y a las características de los ambientes Web. La metodología Medaw toma en cuenta estos factores, sin embargo el proceso de convertir los productos de la metodología en una aplicación sigue estando en manos del desarrollador. En este proyecto se pretende crear un primer prototipo de herramienta de apoyo a la metodología, que permite la creación rápida de prototipos a partir de las vistas y acciones definidas en diagramas de comportamiento que describen los casos de uso de la aplicación. Para este propósito, se ha seleccionado Struts como ambiente para implementar la herramienta permitiendo así futuras mejoras de la misma por parte de sus usuarios. iii

4 Índice general Introducción 1 1. Antecedentes Marco Teórico MVC Struts MeDAW Tecnologías utilizadas XML SVG (Scalable Vector Graphics) Hibernate y XDoclet Planteamiento del problema Descripción del prototipo Diseño Casos de Uso y Diagramas de Comportamiento Formas Modelo Archivos generados Proceso de creación de una aplicación Ejemplo desarrollado Crear un diseño iv

5 Definir los casos de uso y creación de diagramas de comportamiento Definir formas Definir modelo Visualizar archivos Conclusiones Trabajo a futuro Bibliografía 39 v

6 Índice de tablas 3.1. Propiedades posibles en los distintos tipos de campo vi

7 Índice de figuras 1.1. Partes de Struts en MVC [Spi02] Ejemplo de un diagrama de comportamiento Relación entre la metodología MeDAW, el prototipo H-MeDAW y los archivos que genera para una aplicación Struts Crear diseño Lista de diseños con el nuevo Foro El diseño Foro esta vacío Se agrega un nuevo caso de uso Diagrama de comportamiento vacío Se agrega un nuevo nodo al diagrama de comportamiento Se agrega una salida al nodo Diagrama de comportamiento de Registrar Usuario Diagrama de comportamiento de entrar al foro Diagrama de comportamiento de enviar mensaje Se agrega una nueva forma Se agrega un nuevo campo Vista previa de la Forma FRegistrar Forma FEntrar Forma FMensaje vii

8 4.16. Crear Entidad Agregar Atributo Agregar Interrelación Archivos para descargar viii

9 Glosario de Términos A Actor: Concepto que proviene del In the Unified Modeling Language (UML) y que representa a algo o alguien que se encuentra fuera del sistema y que tiene una interacción con éste C Caso de uso: Es un cojunto de secuencias(llamadas escenarios) de posibles interacciones entre el usuario y el sistema. Es uno de los tipos de diagramas de UML y es utilizado por muchas metodologías destacando las derivadas del proceso unificado CGI: Common Gateway Interface por sus siglas en inglés, es un estándar para transferir datos entre un servidor web y un programa externo. Fue la primera manera de crear aplicaciones web, pasando las peticiones hechas al servidor a un programa externo, utilizando variables de ambiente que generaba un archivo en respuesta a la petición, generalmente con código HTML D DOM: (Document Object Model) es una representación de los datos de un documento estructurado (como una página HTML) en donde cada elemento es un objeto que posee sus propios métodos y propiedades. La mayoría de los navegadores contruyen un modelo de este tipo por cada página debido a que Javascript utiliza esta representación para manipular el documento. ix

10 E ER, Diagrama: Diagramas Entidad-Interrelación(entity-relationship) son modelos utilizados para representar datos estructurados. Son usados en el área de bases de datos para visualizar, mediante un dibujo, los diferentes tipos de objetos del dominio y las relaciones entre ellos. G Gecko: Motor de renderizado de páginas web utilizado por todos los navegadores de la familia Mozilla, como por ejemplo Firefox. J Javadoc: herramienta de software que genera documentación para un programa en Java a partir de comentarios en el código. P Properties, archivo: Archivos utilizados en Java para guardar la configuración de una aplicación como un conjunto de pares clave, valor. S SMIL: significa Synchronized Multimedia Integration Language y es un lenguaje estándar de la w3c para animaciones multimedia. Se puede usar en conjunto con SVG para realizar gráficos SVG animados. W Webkit: Motor de renderizado de páginas web utilizado por el navegador Safari de Apple. W3C: son las siglas de World Wide Web Consortium, el consorcio internacional encargado de crear estandares que rigen la Web. x

11 Introducción En los últimos años la web ha pasado de ser un medio de divulgación de información (imágenes y texto) a ser un medio interactivo que permite utilizar aplicaciones para realizar distintas tareas. Empresas y organizaciones están utilizando la web para extender y mejorar la manera cómo hacen negocios. Este crecimiento no es sólo en el número de aplicaciones sino en la complejidad de las tareas que deben realizar. La web no fue creada para alojar aplicaciones sino documentos de hipertexto, pero posteriormente, con el avance de las tecnologías, comenzó a ser usada para aplicaciones. El diseño de aplicaciones web integra diferentes metodologías y tecnologías para cubrir los aspectos de presentación y funcionalidad de las aplicaciones. Estos dos aspectos requieren habilidades muy diferentes, lo que promueve la separación de tareas. Buscando esta separación de tareas los desarrolladores comenzaron a usar para sus aplicaciones web patrones de diseño como MVC (Model - View - Controller), que antes eran usados para aplicaciones de escritorio. Muchos ambientes de programación web como Ruby on Rails, cakephp o Apache Struts han optado por seguir el patrón MVC. La separación de capas que se encuentra en este modelo permite modificar la presentación sin modificar la lógica del negocio y viceversa. Esto permite asignar cada una de las capas a equipos de trabajo diferentes lo que trae muchas ventajas en el costo y el tiempo de desarrollo. Se han creado muchas librerías y frameworks en distintos lenguajes para acelerar el proceso de creación de aplicaciones, muchas de las cuales han decidido utilizar el patrón MVC. El framework más conocido basado en Java se llama Apache Struts. Este aporta una infraestructura para el desarrollo de aplicaciones Web que facilita la separación entre la presentación y la lógica de la 1

12 aplicación, así como la integración entre ambas capas. El elemento principal dentro de una aplicación hecha con Struts es el controlador que se encarga de distribuir cuando una vista hace una solicitud, con qué acción se va procesar y qué vista mostrará la respuesta. En una aplicación Struts se pueden ver los distintos elementos del patrón MVC representados de la siguiente manera: las vistas son implementadas con páginas JSP, el controlador con una clase principal que lee su configuración de un archivo XML denominado struts-config.xml y decide cuál de las Action Classes se encargará de atender esta petición. En estas Action Classes es que se accede y se modifica el modelo [Spi02]. Para diseñar una aplicación Web basada en Struts se requiere de metodologías que se adapten al patrón MVC y que aprovechen las facilidades que brinda Struts. Una metodología que se adapta a estas necesidades es la metodología MeDAW (Metodología de Desarrollo de Aplicaciones Web)[BOS05], que expresa sus diseños en términos de los componentes que deben conformar una aplicación basada en MVC/Struts. En este proyecto de grado se pretende crear un primer prototipo de herramienta que facilite el proceso de diseño previo al desarrollo de la aplicación. El prototipo de la herramienta se llama H- MeDAW. El objetivo es que la herramienta utilice los productos de la metodología (especificaciones y diagramas entre otros) para producir un prototipo que sirva como base para la aplicación final. La herramienta no pretende ser utilizada para el desarrollo de la aplicación completa y a partir del prototipo generado por la herramienta el desarrollador puede usar sus métodos preferidos para desarrollar el resto. Este informe de proyecto de grado comprende 5 capítulos. En el capítulo 1 se presenta el marco teórico, el cual comprende el patrón MVC, la metodología MeDAW, el ambiente de trabajo Struts y otras tecnologías utilizadas. La motivación para crear una herramienta de apoyo a MeDAW aparece en el capitulo 2. En el capítulo 3 se describe el prototipo de la herramienta de apoyo a MeDAW. Un ejemplo de cómo se podría utilizar la herramienta para crear una aplicación se describe en el capítulo 4. Finalmente, en el capítulo 5, se presentan las conclusiones obtenidas a partir de la realización de este proyecto, así como algunas recomendaciones para trabajos futuros. 2

13 Capítulo 1 Antecedentes A continuación se describen brevemente las tecnologías utilizadas en el desarrollo del prototipo de la herramienta, para familiarizar al lector con las mismas Marco Teórico MVC Modelo - Vista - Controlador (en inglés Model-view-controller ) es un patrón de diseño de software utilizado para separar el código, de la interfaz con el usuario, de los datos. Fue descrito por primera vez en los años ochenta con el propósito de programar interfaces gráficas de usuario en el lenguaje de programación Smalltalk[Bur87]. En la actualidad MVC se sigue utilizando para interfaces gráficas, pero también ha incursionado en campos como la programación web. Las tres partes de este patrón representan lo siguiente: Modelo: Es una representación de los datos que utiliza la aplicación. Estos datos vienen acompañados de operaciones que les dan significado y los validan. El modelo ofrece estas operaciones al controlador para que pueda ser modificado. Además, el modelo es encargado de su propia persistencia y no es necesario que los datos sean persistentes para utilizar MVC. 3

14 Vista: Presenta el modelo de una manera que el usuario pueda interactuar con él. Un mismo modelo puede tener varias vistas. Este caso puede darse cuando una aplicación tiene una versión de escritorio y otra versión web. Controlador: es el encargado de responder los eventos iniciados por el usuario y realizar los cambios en el modelo y en la vista. El controlador no modifica los datos directamente, el modelo tiene sus propias operaciones que puede realizar a los datos. El controlador sólo decide cuál operación debe realizar el modelo basada en lo que le comunica el usuario. El patrón MVC es el que utiliza la metodología MeDAW. En las siguientes secciones de este capítulo se puede observar cómo se adaptan ambos al patrón. La comprensión de este patrón por parte del desarrollador es esencial para el buen uso del prototipo Struts Apache Struts (en lo sucesivo, Struts) es un framework o ambiente de trabajo basado en Java utilizado para crear aplicaciones web. Struts se distribuye bajo la licencia Apache 2.0 de código abierto. Fue creado por Craig McClanahan y donado en el año 2000 a la Apache Software Foundation (ASF)[Spi02]. En el año 2005 pasó a ser uno de los proyectos principales de la ASF, cambiando su nombre de Jakarta Struts a Apache Struts. Struts se guía por el patrón MVC (Modelo-Vista- Controlador) para la separación de tareas. Struts está basado en varias tecnologías Java como son las Java Server Pages (JSP) y los Servlets[Spi02]. Los servlets son programas escritos en Java que se ejecutan en el servidor y generan documentos html, xml o de otros tipos, al recibir peticiones en el servidor (el equivalente en Java de los CGI). Existe un servlet que dirige las peticiones que llegan a las diferentes Action Classes para ser atendidas. Este servlet se llama el ActionServlet. Para evitar que este servlet se haga demasiado grande, en vez de modificarlo para cada proyecto, éste lee la información específica de un archivo de configuración xml llamado struts-config.xml. Las Action Classes son otros 4

15 servlets que reciben la información de la petición y utilizan esta información para interactuar con el modelo. En Struts, se puede ver la división del MVC como se observa en la figura 1.1). Los JSP representan las vistas y están formados por una combinación de etiquetas HTML/XML, etiquetas JSP y fragmentos de código llamados scriplets. Se puede colocar código Java dentro de las páginas y atender todas las peticiones desde éstas. El problema de utilizar los scriplets es que convierten los JSP en archivos más largos y con mezcla de lenguajes diferentes, lo que puede complicar mucho el mantenimiento y dificultar la legibilidad de ese código. Las librerías de etiquetas son la herramienta que utiliza Struts para separar estas labores, permitiendo a los autores de los JSP acceder a los datos utilizando etiquetas parecidas a las del xml normal y sin que éste necesite saber del código que se está ejecutando con esa etiqueta[spi02]. Los JSP son una extensión de los servlets por lo que comparten sus reglas de alcance. Cuando un JSP es solicitado por primera vez, el servidor se encarga de compilarlo como una clase servlet para acelerar su ejecución en las siguientes ocasiones. Figura 1.1: Partes de Struts en MVC [Spi02] 5

16 Todos estos elementos son importantes no sólo porque son utilizados por la herramienta, sino porque cada esqueleto de aplicación que produce el prototipo los contiene MeDAW La metodología MeDAW [BOS05] consiste en una secuencia de pasos que llevan al desarrollador desde la descripción del problema hasta la creación del grafo Struts. El grafo Struts es una representación gráfica de toda la aplicación conteniendo los arcos y los nodos de todos los diagramas. Este grafo puede ser utilizado para elaborar o entender el archivo de configuración del controlador struts-config.xml. De manera general la metodología tiene tres etapas: Identificación de casos de uso Elaboración de diagramas de comportamiento Identificación de vistas y acciones El primer paso es común a muchas otras metodologías en el desarrollo de sistemas y consiste en identificar los casos de uso del sistema incluyendo descripción, actor, precondición y postcondición, entre otros. Los casos de uso deben representar los diferentes posibles escenarios y tener una meta clara que debe alcanzar el usuario. El siguiente paso consiste en la elaboración de diagramas de comportamiento. Los diagramas de comportamiento buscan modelar la interacción entre el usuario y el sistema. Se asemejan a la representación de una conversación entre el usuario y el sistema donde se tienen estímulos y respuestas; representando todas los posibles estímulos y las posibles repuestas. Un diagrama de comportamiento estará compuesto por: nodos Usuario: describen las vistas que tiene el usuario del sistema. Cada vista posee una cantidad de opciones que pueden ser tomadas por el usuario. 6

17 nodos Sistema: describen las acciones que debe ejecutar el sistema en respuesta a los requerimientos del usuario, salidas (flechas): que representan comunicaciones entre usuario y sistema, en el caso de las que van de un nodo Usuario a uno Sistema representan una decisión del usuario y en el caso de las que van de un nodo Sistema a un nodo Usuario representan uno de los posibles resultados de la acción de la que vienen. Los nodos Sistema deben ser nombrados y descritos pensando el qué debe hacer el sistema en ese momento y no cómo lo va a hacer, para facilitar la comprensión del diseño. De igual manera, los nodos Usuario deben ser descritos en función de lo que va a contener esa página y no de cómo debe ser presentado. Esto ayuda a separar las labores, el diseñador se preocupa por la información que debe tener cada página y qué labor debe realizar cada acción, dejándole a otros la labor de implementar las acciones o mejorar el aspecto visual de las páginas. Dentro de cada nodo Usuario pueden estar un número de Formas. Cada Forma corresponde a una salida y contiene un número de Campos que son llenados por el usuario; esta información es utilizada por el nodo Sistema al que va esa salida. Una vez creados los nodos, se conectan agregando salidas a cada nodo. Estas salidas son las que verdaderamente representan el orden de la interacción entre usuario y sistema. Cada camino que se pueda formar representa una posible interacción (ver figura 1.2). Finalmente, una vez definidas las Vistas (nodos usuario), las Acciones (nodos sistema) y los arcos (salidas) entre ellas, se elabora el grafo Struts. Para que tenga mayor capacidad de adaptarse a requerimientos cambiantes, MeDAW puede utilizarse iterativamente. Para esto, primero se identifican los casos de uso más importantes y elaborando para ellos los diagramas de comportamiento con sus vistas y acciones. Una vez que el diseño de estos casos esté listo se pueden abordar otros casos de uso de la misma manera. Cabe destacar que tanto los diagramas de comportamiento como otros documentos generados usando 7

18 Figura 1.2: Ejemplo de un diagrama de comportamiento MeDAW tienen también el propósito de documentar la aplicación y servir como herramienta de comunicación entre los desarrolladores. La creación y manipulación de los diagramas de comportamiento, la manipulación de los nodos Usuario y Sistema, así como las partes de la aplicación generada por cada una de estas se discutirán en el capítulo de descripción de la herramienta Tecnologías utilizadas XML XML (extensible Markup Language o en español lenguaje de marcas extensible ) es un metalenguaje de marcas de propósito general desarrollado y recomendado por la w3c [W3C07a]. Proviene del Standard Generalized Markup Language (SGML) y está hecho para describir datos de manera legible a los humanos y facilitar su transferencia. Estas características y la capacidad de desarrollar lenguajes de propósito específico lo convirtieron en un lenguaje ideal para desarrollar aplicaciones 8

19 en Internet. En Struts existen dos archivos xml muy importantes, web.xml que se usa para la configuración general de la aplicación y struts-config.xml que se usa para configurar el controlador maestro y las acciones de la aplicación SVG (Scalable Vector Graphics) La herramienta H-MeDAW brinda al usuario la funcionalidad de crear y manipular los diagramas de comportamiento de forma gráfica. Para generar estos gráficos se utiliza SVG. Es un lenguaje creado para describir gráficos vectoriales tanto estáticos como animados [W3C07b]. Está basado en xml y es un estándar abierto apoyado por la w3c. Al ser gráficos vectoriales se pueden cambiar de tamaño sin deteriorar su calidad y al ser basados en texto facilitan la compresión del archivo. En SVG se pueden representar 3 tipos de objetos: Figuras Vectoriales (Líneas, cuadrados, círculos, etc.) Imágenes de mapa de bits Texto Los objetos SVG pueden ser agrupados, transformados y se les pueden aplicar distintos estilos, máscaras y filtros. Los gráficos SVG pueden ser animados o dinámicos. Para realizar gráficos animados se puede utilizar SMIL para animaciones basadas en tiempo, al estilo de un video. Para gráficos que interactúen con el usuario se usa el lenguaje ECMAScript/Javascript. Para esto, el lenguaje tiene acceso al SVG Document Object Model (DOM) lo que le permite modificar todos los elementos y sus atributos. Es importante destacar que no todos los navegadores de internet soportan la especificación al mismo nivel. El que soporta en mayor medida la especificación es Opera seguido de los navegadores basados en los motores de renderizado Gecko y en Webkit. Para poder ver gráficos SVG en Internet Explorer es necesario instalar un plugin implementado por Adobe [SVG07]. 9

20 Hibernate y XDoclet Hibernate es una herramienta para la plataforma Java que permite hacer un mapeo objetorelacional (ORM, object-relational mapping). Es distribuido como código abierto bajo la licencia LGPL (GNU Lesser General Public License)[Hib07]. Para poder establecer la correspondencia entre la base de datos relacional y el modelo de objetos, Hibernate utiliza archivos xml. Existe una herramienta llamada XDoclet que permite generar estos archivos xml utilizando comentarios hechos en las mismas clases que se quieren guardar. Hibernate ofrece un lenguaje de consultas llamado HQL (Hibernate Query Language). Cuando se hacen consultas con HQL, Hibernate se encarga de producir las consultas SQL necesarias, adaptadas al manejador de bases de datos que se esté utilizando. La idea detrás de las herramientas de ORM es permitir a los desarrolladores preocuparse por las características de su aplicación y no por el cómo van a guardar los datos. La herramienta genera las clases del modelo con comentarios apropiados para poder utilizar Hibernate. XDoclet es un motor de generación de código. Se distribuye bajo la licencia de código abierto BSD. Utiliza etiquetas especiales dentro de los JavaDoc como metadatos para producir el código que genera [XDo07]. En Hibernate, para la persistencia de cada clase Java, es necesario crear otro archivo xml con los datos de persistencia. Usando XDoclet se puede concentrar toda la información en un solo archivo, poniendo la información de la persistencia en los comentarios de los atributos de la clase. 10

21 Capítulo 2 Planteamiento del problema Las metodologías de desarrollo como MeDAW describen un proceso para producir software. Cada metodología abarca distintos ámbitos, como el diseño y especificación, realización de pruebas, implementación y documentación, entre otros. Los productos de una metodología pueden ir más allá del software e incluyen en muchos casos otros documentos y diagramas. La metodología MeDAW pretende guiar únicamente el diseño y especificación dejando en las manos del desarrollador la decisión de que metodología utilizar en los otros aspectos como la implementación. Los productos de la metodología para una aplicación ya diseñada consisten en los diagramas de comportamiento de los distintos casos de uso y la descripción de las formas, ambos explicados en el capítulo 3. Los desarrolladores pueden elaborar estos productos sin ninguna herramienta de apoyo pero eso trae como consecuencia varios problemas. Los diagramas de comportamiento requieren de la realización de dibujos de rectángulos y flechas. Realizarlos en papel dificulta su modificación y exige una dedicación de tiempo para asegurar su uniformidad y proporcionalidad. Para evitar los problemas de la realización manual, podrían utilizarse programas de dibujo de diagramas como Microsoft Visio [Vis07]. Como ninguno de dichos programas tiene entre sus formas disponibles las necesarias para un diagrama de comportamiento, habría que crear una librería de formas. 11

22 Aún logrando todo esto los diagramas resultantes serían sólo dibujos. Para poder empezar a codificar la aplicación, el desarrollador debe empezar desde el principio teniendo como referencia los diagramas. MeDAW está diseñada para desarrollar aplicaciones en ambiente Struts. El hecho de ser tan específica permite ver correspondencia directa entre varios de los elementos del diseño y las partes de una aplicación Struts. La motivación para la creación de una herramienta viene de querer solventar estos problemas y apoyar a los desarrolladores que utilizan la metodología. El prototipo H-MeDAW tiene dos objetivos principales: Facilitar la creación de los diagramas de comportamiento con todas sus partes. Los diagramas de comportamiento deben ser fáciles de crear y manipular. Generar un conjunto de archivos de la aplicación basándose en los diferentes diagramas de comportamiento. Esto ahorra al desarrollador el tener que escribir una cantidad considerable de código. El desarrollador sólo debe completar algunos archivos y crear otros en vez de tener que crear todos desde el principio. El prototipo busca que los modelos realizados utilizando la metodología sirvan para generar un conjunto de archivos que forman el esqueleto de la aplicación, disminuyendo así la repetición innecesaria de código. Aun así todos estos archivos deben ser completados para poder hacer funcionar la aplicación. Las herramientas similares a H-MeDAW como Expresso c [Ltd07], Exadel Struts Studio c [Exa07], MyEclipse c [IDE07], MDE c [fs07] proveen ciertas facilidades como introducir los datos a través de cajas de diálogo o ver los archivos de configuración en forma de gráfico que conecta las diferentes páginas Struts. Estas facilidades aceleran un poco el trabajo pero igual requieren un profundo conocimiento de Struts y no aportan nada a la documentación del sistema. H-MeDAW pretende llevar al usuario a un nivel de abstracción más alto. Los diagramas de comportamiento son fáciles de entender y crear, aún para las personas con poca o ninguna experiencia en Struts, aunque el tener experiencia previa puede ayudar a acelerar el proceso de creación. Además los diagramas 12

23 de comportamiento brindan una documentación valiosa para el sistema. El prototipo pretende dar un punto de partida más adelantado al desarrollador, generando archivos. En otras palabras, esta herramienta está orientada a facilitar el proceso de diseño, previo al desarrollo de la aplicación. En la figura 2.1 se puede ver la relación entre la metodología y los objetos que permite manipular el prototipo. También se puede ver la relación entre los objetos de la metodología y algunas partes de una aplicación Struts. 13

24 Figura 2.1: Relación entre la metodología MeDAW, el prototipo H-MeDAW y los archivos que genera para una aplicación Struts 14

25 Capítulo 3 Descripción del prototipo Este prototipo (H-MeDAW) tiene como finalidad apoyar al usuario en la aplicación de la metodología MeDAW, brindándole mecanismos adecuados para diseñar una aplicación web basada en Struts. Esta herramienta esta hecha como una aplicación Struts con un modelo que utiliza Hiberate para la persistencia. El hecho de que la herramienta es una aplicación del mismo tipo de los prototipos que produce hace posible que un futuro prototipo pueda ser creado utilizando el primero. En la figura 2.1 se observa el marco de referencia asociado a MeDAW, en particular, los pasos y los productos que se generan Diseño El prototipo utiliza el concepto de diseño para representar una aplicación que se esté desarrollando con él. Dentro de cada diseño se encuentran todos los casos de uso con sus diagramas de comportamiento, las formas y el modelo. La idea detrás de esto es que se pueda trabajar paralelamente en varias aplicaciones diferentes. Cada diseño cuenta con un nombre y una descripción para documentar su intención, mostrando los archivos de ese diseño únicamente. 15

26 Casos de Uso y Diagramas de Comportamiento Cada caso de uso representa una o más secuencias de interacciones entre el usuario y la aplicación. Estas secuencias están relacionadas a una meta especifica que pretende conseguir el usuario, aunque pueden existir secuencias donde no se logre la meta. Tanto los diseños como los casos de uso están hechos para separar interacciones y acciones relacionadas entre sí, de otras que no lo están. En el prototipo actual, los archivos generados por todos los casos de uso se ubican juntos. La información de casos de uso podría ser utilizada, en futuras versiones, para permitir al desarrollador separar los archivos por carpetas. La información necesaria para crear un nuevo caso de uso es: un nombre, un actor, un nodo inicial y una descripción. El nombre del caso de uso funciona como su identificador lo que no permite dos casos de uso con el mismo nombre dentro del mismo diseño. El diagrama de comportamiento permite ver gráficamente las secuencias de interacciones en el caso de uso. Los diagramas de comportamiento siempre deben comenzar por un nodo Sistema, por esta razón se pregunta en el proceso de creación del caso el nombre de su nodo inicial. Una vez creado el caso de uso, se puede proceder a agregarle sus nodos Usuario y Sistema. Los nodos Sistema representan las acciones realizadas por la aplicación que se está diseñando. Los nodos Sistema reciben información, la procesan y llevan al usuario a otra página utilizando sus salidas. En el momento de generar los archivos de la aplicación, cada nodo Sistema de un diseño se traduce en una clase de tipo action class que representa una acción en Struts y una declaración de esta acción dentro del archivo struts-config.xml. Un nodo Sistema está identificado con dos nombres; uno corto y uno largo. El nombre corto sirve para el nombre de la acción que representa tanto en el struts-config.xml como en el nombre de la clase. Por esta razón el nombre corto debe seguir las reglas de nombre para una clase Java. El nombre largo es mucho mas explícito y fácil de identificar con el nodo que representa. Además de sus dos nombres los nodos Sistema poseen una descripción, una forma y una campo de código. La descripción nos permite entender más a fondo la función que debe realizar ese nodo. Esta descripción se agrega como comentario en la action class para 16

27 ayudar al desarrollador. El código es un espacio para escribir un trozo de código Java, en el archivo generado se agrega el código tal cual aparece. Este campo no es obligatorio pero puede ser útil si quien está diseñando la aplicación conoce Struts o si se está modelando una aplicación preexistente de la que ya se tiene código. La Forma indica que para su ejecución el nodo requiere de los datos de esa Forma. El primer prototipo no genera ningún aviso si se apunta una salida que no tenga la Forma a este nodo. Realizar esta verificación sería una mejora muy útil al prototipo. Existen los dos nombres porque el nombre largo es necesario para identificar el propósito del nodo pero, generalmente, no cumple con los requisitos de un nombre de una acción Struts. Una posibilidad era generar el nombre corto a partir del largo eliminando todos los caracteres no válidos o utilizando alguna estrategia similar, pero esto podría traer como consecuencia nombres que dificultarían la lectura del struts-config.xml por parte de otros desarrolladores. Se decidió dejar que el usuario escogiera el nombre corto de los nodos pensando que él puede seleccionar un nombre más apropiado que cualquier sistema automatizado. Los nodos Usuario representan las acciones que puede elegir el usuario en su interacción con el sistema. Cada nodo Usuario se traduce como una página JSP donde se le presentan al usuario sus opciones. Un nodo Usuario también tiene dos nombres, el corto y el largo. Las razones para tener los dos nombres son las mismas que en los nodos Sistema. En el caso de los nodos Usuario el nombre corto es usado como nombre del archivo JSP. Adicionalmente, los nodos Usuario también poseen una descripción para entender qué opciones se le están presentando al usuario. En el JSP generado se agrega el nombre largo como encabezado y la descripción como texto. Las salidas de cada nodo contienen un nombre, una forma y un destino. En los nodos Sistema, los nombres de cada salida son agregados como posibles respuestas en el código. En los nodos Usuario, las salidas agregan el código de su Forma al respectivo JSP. El destino es lo que permite conectar unos nodos con otros. Para especificar el destino se debe escribir el nombre corto del nodo, seguido de una seguido del nombre del caso de uso al que pertenece. En futuras versiones del prototipo, se espera que no sea necesario el escribir a donde va una salida sino que se pueda crear 17

28 en el diagrama de comportamiento tan fácil como dibujar una flecha de un nodo a otro Formas Las Formas representan la parte de los archivos JSP donde los usuarios pueden introducir datos. Cada una tiene nombre y descripción, que se incluyen en cada página que contiene la Forma, para ayudar al desarrollador, y una colección de campos que representan los distintos tipos de entrada de datos. Estos tipos de campos son: Tipo texto Tipo contraseña Tipo botones radio Tipo menú desplegable Tipo área de texto Botón de enviar Botón de limpiar Las Formas deben estar asociadas, obligatoriamente, a una salida para poder poner en el campo action quien se encargará de esos datos una vez sean enviados. Cada campo tiene propiedades con las que se puede modificar un poco la manera como se ve o se comporta (ver cuadro 3.1). Por ejemplo, en los campos de entrada de texto simple, se puede poner el máximo número de caracteres permitidos o en los de área de texto poner cuantas columnas y filas debe tener el área. En los campos de selección simple o múltiple se pueden agregar propiedades de tipo option que representan las distintas opciones posibles para esa selección. Las Formas también generan un bean de Java que extiende a la clase ActionForm. Este bean contiene un atributo por cada campo de la Forma. Struts utiliza este bean para llenarlo con los datos 18

29 Propiedad Significado Campos size Tamaño del campo expresado en número de caracteres textinput, password maxlength Tamaño máximo en número de caracteres del texto textinput,password rows Número de filas disponibles en una área de texto textarea cols Número de columnas disponibles en una área de texto textarea value Texto por defecto para llenar el campo textinput, textarea option Agrega una opcion a los campos de seleccion select,radio,checkbox opcionselec Agrega una opcion preselecionda a los campos de eleccion select,multi-select Tabla 3.1: Propiedades posibles en los distintos tipos de campo de la petición y pasarlo lleno con los datos a la acción correspondiente. En el struts-config.xml se agrega una declaración con el nombre de la Forma y el bean que la representa Modelo Struts no provee ningún software ni ninguna estrategia para construir el modelo de una aplicación. El modelo depende de como el desarrollador desea representar sus datos. Crear el modelo requiere conocer la lógica del negocio y la naturaleza de los datos por lo que la cantidad de ayuda que se puede prestar en ese aspecto no es tanta como en los otros casos. Como se vió en el capítulo 1, una aplicación no tiene que tener persistencia en su modelo. Aun así en muchos casos la persistencia de los datos es necesaria. Es en este aspecto de la persistencia que otros frameworks intentan apoyar a sus desarrolladores. Struts permite a sus desarrolladores utilizar cualquier método de persistencia disponible para Java. Uno de los métodos más populares para esto es la utilización de Hibernate descrito en el capítulo 1. La metodología MeDAW tampoco obliga a nada al momento de construir el modelo. Sin embargo, en este primer prototipo de H-MeDAW se decidió agregar un módulo que ayuda al desarrollador a crear su modelo y hacerlo persistente. En este nodo el usuario puede crear entidades e interrelaciones. Se usan estos términos (entidades e interrelaciones) porque se intentan modelar los datos utilizando un modelo ER. Cada entidad es traducida en una clase y puede tener atributos de cualquier tipo de datos válido en Java. Las interrelaciones se usan para mostrar la conexión entre las distintas 19

30 entidades o clases; éstas, dependiendo de su tipo, generan código en alguna de las dos entidades participantes o generan una clase nueva. Cada una de estas clases posee comentarios especiales que son utilizados por XDoclet para generar archivos de configuración de Hibernate. Este módulo es el menos avanzado de los tres y es de uso opcional. Los archivos generados por este módulo son independientes de los archivos generados por los otros módulos. Si un desarrollador desea utilizar otro método para la creación y persistencia de su modelo, puede hacerlo Archivos generados En la sección de archivos se encuentran todos los archivos que deben ser descargados para formar el esqueleto de la aplicación. Para usarlos deben ser copiados en un proyecto Struts en blanco y recompilar. Se ofrecen los archivos de esta manera para que el desarrollador pueda bajar los que necesite, en el momento que necesite. Sólo se ofrecen los archivos relevantes para la herramienta. Para tener una aplicación de Struts completa deben copiar estos archivos generados en una aplicación Struts en blanco. 20

31 Capítulo 4 Proceso de creación de una aplicación En este capítulo se presentan los pasos en la creación de un esqueleto de aplicación. La aplicación es sencilla y se explicará cada paso brevemente para dar una idea general al lector de las capacidades de la herramienta. En caso de necesitar varios pasos iguales (crear varios casos de uso) sólo se explicará uno y se indicará que deben ocurrir los demás Ejemplo desarrollado Como ejemplo se usará una aplicación de foro en línea. Los usuarios se registran en el foro dando un nombre, contraseña y otros datos. Una vez registrado, el usuario puede entrar al sistema. En el sistema se despliega una lista con los mensajes publicados por otros usuarios y se da la opción de agregar un mensaje nuevo Crear un diseño Lo primero que se necesita crear es un diseño. Al acceder a la aplicación, lo primero que se ve es una lista de diseños ya creados y el vínculo a crear un nuevo diseño. Al elegir este vínculo, se piden los datos necesarios para crear el nuevo diseño. Se crea un diseño llamado Foro (fig 4.1). Después de creado el diseño llamado foro, aparece en la lista de diseños creados(fig 4.2). 21

32 Figura 4.1: Crear diseño. Figura 4.2: Lista de diseños con el nuevo Foro 22

33 Una vez creado el diseño llamado Foro, se entra en este diseño vacío (fig 4.3) para ir creando sus diferentes partes como se indica en las siguientes secciones. El proceso se separó en tres partes, el orden indicado aquí no tiene por que ser el orden usado para desarrollar aplicaciones. Las tres partes pueden ser hechas por personas diferentes y en cualquier orden. Figura 4.3: El diseño Foro esta vacío Definir los casos de uso y creación de diagramas de comportamiento La aplicación del Foro tendrá tres casos de uso principales: registrar usuario, entrar al foro y enviar mensaje. El registro consiste en agregar un usuario nuevo al conjunto de usuarios del foro. Entrar al foro consiste en proveer un nombre de usuario y una clave para poder entrar a ver los mensajes. Enviar mensaje consiste en enviar un mensaje para que aparezca en el foro. Sólo se mostrarán los pasos detallados para crear uno de los casos de uso, pero se mostrará el diagrama de comportamiento resultante en los tres casos. Para crear un nuevo caso de uso se debe introducir el nombre, actor, nodo de inicio y la descripción. El nombre y el nodo de inicio son campos obligatorios mientras que los otros son opcionales. El primer caso de uso a crear es Registrar usuario (fig 4.4) Una vez creado el caso de uso, se comienza a crear el diagrama de comportamiento agregándole nodos. Esto se puede hacer editando el diagrama de comportamiento vacío (fig 4.5) o desde la vista textual. Primero se agrega el nodo inicial que se había definido cuando se creó el caso de uso. Para crear el nodo Sistema se necesita un nombre, un nombre corto, forma, descripción y código. 23

34 Figura 4.4: Se agrega un nuevo caso de uso Figura 4.5: Diagrama de comportamiento vacío 24

35 El nombre y el nombre corto son obligatorios. El nombre corto se utiliza como nombre del archivo a generar y como identificador de la acción, debe cumplir con las normas de nombre para una clase java. El nombre ayuda a entender de qué se trata este nodo y puede contener espacios. Se crea el nodo Sistema de nombre Inicio Registrar y nombre corto iniregistrar (fig 4.6). Figura 4.6: Se agrega un nuevo nodo al diagrama de comportamiento Luego se agrega una salida de este nodo a otro nodo usuario llamado registrarse. Las salidas deben tener un nombre, un destino y opcionalmente una forma. En la primera versión del prototipo se debe colocar en destino el nombre del nodo seguido de y el nombre del caso de uso al que pertenece(fig 4.7). Para continuar elaborando el diagrama, se agrega el nodo Usuario al que se apuntó en la salida anterior. Los nodos Usuario poseen tres campos (nombre, nombre corto y descripción) que tienen la misma finalidad de esos campos en los nodos Sistema. Se agrega una salida a esta nueva Forma para seguir con el diagrama. Esta salida debe tener como forma la que contiene los datos de registro llamada FRegistro. Por último, en este diagrama de comportamiento se agrega otro nodo Sistema encargado de 25

36 Figura 4.7: Se agrega una salida al nodo procesar el registro. A este último se le agrega una salida que va al nodo inicial del diagrama del caso de uso Entrar al foro. En la figura 4.8 se puede ver el diagrama de comportamiento del caso de uso registrar. No existe ninguna salida del nodo Registrar un usuario de regreso al nodo usuario se registra aunque una interacción común es que una forma tenga algún dato erróneo y el sistema devuelva al usuario a la misma para que lo corrija. Esto se debe a que en Struts todas las formas tienen un método de validación. Sólo es necesario poner una salida de regreso en caso que no se desee usar este método. Los otros casos de uso se crean siguiendo una secuencia parecida a la anterior hasta obtener lo mostrado en las figuras 4.9 y

37 Figura 4.8: Diagrama de comportamiento de Registrar Usuario Figura 4.9: Diagrama de comportamiento de entrar al foro 27

38 Figura 4.10: Diagrama de comportamiento de enviar mensaje Definir formas En la sección anterior se menciona una forma llamada FRegistro. Esta forma sirve para que el usuario pueda introducir sus datos personales. Se crea la forma con un nombre y una descripción como se ve en la figura Figura 4.11: Se agrega una nueva forma Posteriormente se añaden todos los campos deseados a la forma (fig 4.12). Cada campo posee 28

39 un nombre, una etiqueta que aparece a su lado en la página y un tipo. La forma de registro contiene varios campos de distintos tipos incluyendo: nombre (Tipo texto) correo electrónico (Tipo texto) clave (Tipo Contraseña) sexo (Tipo botones radio) país (Tipo menú desplegable) firma (Tipo área de texto) Figura 4.12: Se agrega un nuevo campo Cada vez que se agrega un elemento nuevo a la Forma podemos ver el nuevo aspecto de la forma en la vista previa. Cuando se termina la definición de la forma (fig 4.13), lo que hace falta para que aparezca en una página es asociarla a una salida como en la sección de Formas de este capítulo. Las otras dos formas son la forma FEntrar y FEnviar. La de entrar sólo requiere el nombre y la clave del usuario. La de enviar mensajes sólo tiene un área de texto para el mensaje y los botones 29

40 Figura 4.13: Vista previa de la Forma FRegistrar de enviar y limpiar. A continuación pueden verse los detalles y la vista previa de cada una de estas formas en las figuras 4.14 y Figura 4.14: Forma FEntrar 30

41 Figura 4.15: Forma FMensaje 31

42 Definir modelo La aplicación del foro sólo contiene dos elementos que deban ser guardados de manera persistente, los usuarios y los mensajes. Cada uno de estos posee una entidad en el modelo de datos. Los mensajes son escritos por un único usuario, lo que relaciona a ambas entidades. Se deben crear entonces dos entidades y una interrelación. Al crear una entidad se debe dar un nombre y una descripción. Antes de poder usar la entidad se deben agregar atributos. Cada atributo tiene un nombre y un tipo de datos. Este nombre debe ser un nombre de variable correcto y el tipo, es decir un tipo de datos correcto en java. Se crea la entidad usuario (fig 4.16) y se le agregan los mismos campos que tiene la forma FRegistro (fig 4.17). Figura 4.16: Crear Entidad Figura 4.17: Agregar Atributo 32

43 Para crear los mensajes se repite el proceso de manera similar a los usuarios. Posteriormente se agrega la interrelación entre las dos entidades (fig 4.18). Para esto se necesita un nombre, las dos entidades y la participación de cada una en la relación, que son los atributos de una relación en un diagrama ER. Figura 4.18: Agregar Interrelación Visualizar archivos Desde cualquiera de las páginas del diseño se puede acceder a la sección de archivos (fig 4.19). En esta sección se generan todos los archivos que conforman el esqueleto de la aplicación. El usuario puede ir viendo cómo van evolucionando estos archivos y descargarlos cuando crea que su diseño esté listo. El usuario puede ir realizando cada caso de uso y descargarlos mientras se encargue manualmente de mezclar los archivos comunes como el struts-config.xml. De esta manera no se tiene que diseñar toda la aplicación antes de escribir el código. 33

44 Figura 4.19: Archivos para descargar. 34

45 Capítulo 5 Conclusiones Con la culminación de este proyecto de grado se logró diseñar e implementar un prototipo de herramienta de apoyo para la metodología MeDAW [BBOS07]. El prototipo H-MeDAW fue desarrollado como una aplicación Struts para permitir que sus usuarios puedan ver el código, entenderlo y mejorarlo. Además de Struts se utilizó Hibernate como tecnología para mantener los datos persistentes de los diseños. El prototipo consta de tres partes o módulos: casos de uso/diagramas de comportamiento, formas y modelo. Cada uno puede ser usado de manera separada, pero es el de casos de uso/diagramas de comportamiento el más importante, ya que le da a las aplicaciones generadas las características de una aplicación Struts. El módulo de casos de uso/diagramas de comportamiento permite al usuario crear e ir describiendo la interacción que ocurre entre el usuario y el sistema a través de sus diagramas de comportamiento. A estos diagramas se le agregan nodos tanto Sistema como Usuario y se van conectando utilizando salidas. Los diagramas de comportamiento tienen doble función: la de documentar el diseño y la de generar las páginas JSP, las acciones y el archivo de configuración del controlador struts-config.xml. El módulo de formas es el más ligado con el módulo de casos de uso. Las formas son utilizadas para solicitar información al usuario en una página JSP y pasarla a una acción para que se encargue 35

46 de procesarlas. El prototipo permite crear las formas e ir visualizando el resultado. Los campos de las formas pueden ser modificados agregando propiedades; estas propiedades afectan el cómo se ve y cómo se comporta cada campo. En este primer prototipo el número de propiedades que acepta cada tipo de campo es limitado pero es posible extenderlo para futuras versiones. Cada forma genera un nuevo form bean, se incluye una entrada en el archivo struts-config.xml para éste, y el código de la forma en la página JSP correspondiente. Aunque la generación de archivos que representan al modelo no estaba incluida en el proyecto original, se decidió incluirla porque le da un valor agregado al desarrollador y completa el tercer aspecto de MVC que los otros dos módulos no tocan. Sin embargo, este módulo es el menos avanzado de todos. Este módulo crea entidades e interrelaciones y genera clases java a partir de ellas. Estas clases tiene unos comentarios especiales que son convertidos con XDoclet en archivos de configuración de Hibernate. Las ventajas de este módulo representan una funcionalidad opcional, ya que si el desarrollador no desea usar Hibernate para la persistencia de sus datos no tiene que usar este módulo. Este prototipo H-MeDAW es una primera aproximación a la versión final de la herramienta. Existen varios aspectos en los que pueden ser incorporadas algunas mejoras. Además debe ser probado en ambientes de producción para encontrar sus posibles fallas y ampliar su funcionalidad. La mayor de estas mejoras sería evitar corte en el paso de la fase de diseño a la fase de implementación y poder pasar del diseño a la aplicación y de regreso. Esto evitaría que si se generan y modifican los archivos, al generarlos nuevamente se pierdan los cambios que se habían realizado. Aun así, el prototipo se encuentra en un estado utilizable y genera aplicaciones Struts válidas. H-MeDAW le da al desarrollador la posibilidad de enfocarse en los aspectos particulares del diseño de su aplicación. La herramienta ahorra al desarrollador el tener que escribir código genérico y le deja concentrarse en el código específico de la aplicación. Todo esto permite que el desarrollador pueda crear, mas rápido, una aplicación mejor documentada. 36