MetodologiaUMLWeb

Modelado de aplicaciones Web mediante UML Inmaculada Blanco Sierra Miguel Angel Almudéver Galán . Facultad de Informática - Universidad Politécnica de Valencia Las Aplicaciones Web ya forman parte de nuestro qué hacer cotidiano. Si hasta hace poco tiempo sólo se esperaba el recoger cierta cantidad de información de una página Web, hoy no se concibe el no poder interactuar con ella. Se sigue buscando la información, pero sólo aquella que el usuario considera interesante. El desar esarro roll llo o de Inte Intern rnet et,, el come comerc rcio io elec electr tró ónico nico y las las tecnologías de la información orientan el futuro de las aplicaciones a un entorno global, donde cualquier usuario al que se le permita el acceso pueda interactuar con el entorno. Dicho entorno se deberá comportar en función de lo que exija el usuario, lo que permitirá a una Aplicación Web distinguirse de una simple página o incluso de una página dinámica. Y para alcanzar el objetivo propuesto sobre estas líneas, es nece necesa sari rio o un mode modela lado do capa capaz z de reco recoge gerr y most mostra rarr toda todas s las las estructura estructuras, s, formas y componen componentes tes presentes presentes en el entorno entorno Web. A continuación vamos a ver como hacerlo...

DESARROLLO DE APLICACIONES WEB Introducción Gracias al desarrollo de nuevas herramientas y tecnologías, las Aplicaciones Web son cada vez más populares. La facilidad de su desa desarr rrol ollo lo prov provoc oca, a, a vece veces, s, la ause ausenc ncia ia de un anál anális isis is y dise diseño ño correc correctos tos,, pero pero están están consig consiguie uiendo ndo reempl reemplaza azarr a las aplica aplicacio ciones nes software software tradicionales. tradicionales. Lo que aquí vamos a ver es una presentación presentación genérica del funcionamiento y estructura de dichas aplicaciones. En este documento nos vamos a encontrar con tres partes bien definidas para el desarrollo de una aplicación Web. En primer lugar, verem veremos os la arqu arquit itec ectu tura ra de dich dichas as apli aplicac cacio ione nes. s. A cont contin inua uaci ción ón veremos el porqué de utilizar UML para su modelado. Y finalmente haremos un recorrido por los distintos elementos que las componen y sus posibilidades de evolución en un futuro próximo.

1

Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia

Arquitectura de una Aplicación Web Sitios Web Una Aplicación Web es un sitio donde la entrada de datos afecta al estado de la lógica. Es decir, una Aplicación Web se sirve de un sitio o página como entrada a una verdadera aplicación. Veamos

primero la estructura de un sitio Web: Figura 1: A la izquierda tenemos la arquitectura de un sitio Web tradicional, y a la derecha uno dinámico.

Aplicaciones Web A veces la distinción entre una Aplicación Web y un sitio Web es muy sutil – por ejemplo, un buscador forma parte de un sitio Web, mientras que si se acepta información para registrar a un usuario, se trata de una Aplicación Web -. De todas maneras, lo que sí es evidente es que la arquitectura global de una Aplicación Web es idéntica a la de un sitio Web, aunque su desarrollo sea más elaborado.

Páginas Las páginas son el componente fundamental de las aplicaciones Web, y se muestran a través de los navegadores que hacen de contenedores del interfaz de usuario. Estas páginas son el resultado de la combinación de páginas HTML junto con scripts de páginas dinámicas. El nuevo formato obtenido como mezcla de los dos anteriores será lo que mostrará el navegador. Los scripts pueden contener tanto variables como procedimientos y funciones, cuyo objetivo final es actuar sobre el servidor de manera que: - Se actualice el estado de la lógica del servidor. - Se creen las nuevas páginas que debe mostrar el navegador. 2


Una cosa importante a tener en cuenta es que el servidor no es el único elemento capaz de ejecutar scripts. Un navegador también es capaz de hacerlo, aunque presenta el inconveniente de que no tiene acceso al servidor, con lo que su trabajo se limita al control de datos y asistencia en la navegación. En general, los procedimientos del lado del servidor son procedurales, mientras que los del lado del navegador o cliente son dirigidos por eventos.

Formas Las formas más comunes de introducir información son las áreas de texto, listas de selección o botones de radio, por ejemplo. Cada uno de estos elementos tiene un nombre o ID asociado a una página de acción, y cuando el usuario introduce la información, el servidor interpreta o ejecuta el código contenido en dicha página. El resultado, la información introducida por el usuario puede ser procesada.

Componentes Hay Aplicaciones Web que se sirven de una tercera capa de componentes, entre el interfaz de usuario y el sistema permanente, que suele estar formado por objetos compilados que funcionan en un servidor de aplicaciones. Esta capa sólo se utiliza cuando la lógica necesaria para controlar la aplicación es muy extensa y el tiempo es un factor crítico en las decisiones de diseño. Las páginas formateadas en HTML también pueden tener referencias a componentes en la máquina del cliente, como son los JavaApplets o los controles ActiveX. Su presencia supone la extensión de la Aplicación Web al cliente y nuevas posibilidades en cuanto a la interfaz con el usuario, puesto que aumentan la interacción que pueden ofrecer las páginas preformateadas.

Frames Las capacidades de la interfaz de usuario pueden ser incrementadas con el uso de frames, que permiten tener varias páginas abiertas y activas al mismo tiempo.

3


Figura 2 : estructura de una página Web

Otros Componentes Con los componentes ya mencionados, se puede desarrollar una buena Aplicación Web, aunque otros componentes más recientes pueden afectar su arquitectura, como son el caso de XML y los scriptlets. Estos últimos tienen el inconveniente de que sólo funcionan en navegadores Microsoft.

Modelado Una de las metodologías o notación empleadas en la modelización de sistemas Web es la “Metodología Relacional” ( RMM, Relationship Management Methodology ), es una metodología para el diseño, construcción y mantenimiento de sistemas web para intranets e internet. Su principal objetivo es la reducción de costes de mantenimiento de sitios Web dinámicos dirigidos por la base de datos. Pero esta metodología falla a la hora de construir aplicaciones Web, en las que la lógica de negocio es la parte central, ya que no las cubre adecuadamente. Las aplicaciones Web pueden ser usadas como mecanismo servidor para aplicaciones distribuidas, y además pueden crear múltiples instancias del mismo browser y frames en la parte cliente que deben establecer y mantener su propio mecanismo de comunicación. Todo esto debe ser modelizado también y RMM no es capaz de hacerlo. La elección de una notación debe estar en función de la necesidad de modelizar la parte de las capas de la parte del servidor. Con la admisión de UML como notación para la modelización cada vez más sistemas están siendo modelizados con él ya que es capaz de 4


expresar la lógica del sistema en los componentes Web, a lo largo del resto de la aplicación. Otro de los modelos importantes ADM ( analisis/desing Model) representa alguna dificultades cuando trata de modelizar páginas Web y el código ejecutable asociado a éstas relacionándolo con el resto de elementos en el modelo. Decidir cómo modelizar ,determinar el grado de abstracción y el detalle que queremos alcanzar es crítico para los usuarios de ese modelo. En UML, los links representarían el path de navegación desde una página a otra. Extendiendo esta forma de pensar las páginas serían clases en la vista lógica del modelo, por lo tanto los scripsts de las página serían operaciones ( métodos ) de la clase, y las variables de estos scripts cuyo ámbito sea la página, serían los atributos, pero esto no nos ayuda cuando tenemos que saber que operaciones, atributos,etc están activos en el servidor, por lo tanto es mejor modelizarlas como componentes del sistema. Un sistema puede ser modelado de diferentes maneras, y todas ellas consistentes. Sin embargo, asumiremos que el centro de dicho sistema será una página. Esto levanta las siguientes dudas: una página puede ser modelada como un objeto, pero ¿ cuáles son sus atributos ?. Pues bien, deben de ser aquellos elementos que afecten al comportamiento del sistema, es decir, los scripts, por ejemplo. Y esto suscita un nuevo desafío : el cómo modelar dicho sistema cuando tanto el servidor como el cliente ejecutan scripts, puesto que compartir atributos o métodos entre ambos puede llegar a ser muy confuso.

Extensiones del modelado UML no es perfecto para todas las situaciones, y es por ello que se definen mecanismos de extensión como las Etiquetas, Estereotipos y Restricciones. Para resolver el problema presentado anteriormente, se podrían definir los Estereotipos <> y << método de servidor >>, que nos permitirían hacer una distinción adecuada en el diseño. Aún así, al representar las relaciones no se garantiza que sólo sean válidas desde el lado del servidor o el del cliente…

Estereotipos de página Una mejor solución al modelado de páginas pasa por la creación de dos clases con estereotipo: Página de servidor •

5


•

Página de cliente

Su implementación puede aparecer en el mismo fichero o componente, pero la distinción es clara. Mientras la página de servidor se ocupa del acceso a los componentes, scripts, datos y, u otros elementos que se encuentren en la parte del servidor, la página del cliente se ocupa de los Applets de Java, los controles ActiveX y, o el formateado de la página, por ejemplo. Veamos los estereotipos en detalle. 1. Hay una relación importante entre ambas páginas, definida unidireccional y descrita bajo el estereotipo <>. Y es que una página de servidor se encarga de construir una de cliente. Incluso podría darse el caso de que una página de servidor construya varias de las páginas cliente. 2. Otro estereotipo es el definido como <>. Dependiendo de la entrada y de las exigencias de procesado, una página de servidor puede redirigirse hacia otras que cumplan una labor más específica. Redirigir toma en este caso el significado de delegar. 3. <>. Es algo más sutil que los anteriores y se sumaría a un diagrama que ya conste de un estereotipo <>. Una página de servidor construye una de cliente y, bajo ambas, existe un elemento Web que se da cuenta, que presencia, al menos una de ambas páginas. Un componente Web presenciaría ambas páginas a la vez. 4. Una relación que no se puede olvidar viene definida por el estereotipo <>. Y sabiendo lo que significa un hiperenlace, está claro que sólo tiene sentido definirlo desde una página cliente hacia una página servidor – que generará una nueva página cliente -, o desde la página cliente hacia otra de su misma clase. Si dicho enlace contiene parámetros, se modelan fuera de la relación.

Componentes Los componentes, presentados como interfaces disponibles para los distintos objetos - por ejemplo, DLLs, controles ActiveX... -, se identifican como <> o <>, para poder diferenciar quién puede servirse de ellos.

6


Formas El significado de una forma se puede resumir diciendo que una página cliente contiene formas. Es decir, las formas existen porque hay una serie de atributos que no tienen significado a lo largo de toda la página cliente, y porque además desde dicha página queremos llegar a destinos diferentes. De aquí se puede deducir que una forma no tenga métodos y que los métodos de una página cliente tengan acceso a los atributos de todas las formas en ella contenidas. Por tanto, hemos de considerar el estereotipo <> que a su vez va a generarnos otro nuevo: <>. Dicho estereotipo se justifica con la necesaria relación entre una forma y la página que la procesa. Es más, la relación es bidireccional puesto que la página que va a llevar a cabo el proceso tiene acceso a los atributos de la forma, que son enviados en tiempo de ejecución.

Framesets Los framesets o conjuntos de marcos aparecen con la posibilidad de mostrar varias páginas Web al mismo tiempo. Puesto que un frameset puede contener cualquier página cliente, debemos considerarlo como una especialización de las mismas y, con ello, generar un nuevo estereotipo <>. Coordinar la actividad entre las páginas requiere la habilidad de poder referenciar las páginas dentro de los marcos, y a dicha referencia la llamaremos objetivo. Un objetivo es muy distinto de un marco y una página sólo puede referenciar objetivos de navegadores abiertos, así que nos vamos a crear un nuevo estereotipo para mostrar tal descripción: <>. La mayor ventaja de haber creado dicho estereotipo es que puede ser compartido y referenciado por muchas páginas cliente. No posee atributos ni métodos. Pero surge una especialización del mismo : cuando queremos cargar un enlace en un navegador distinto de sí mismo. En este caso, estamos frente a un nuevo estereotipo que llamaremos <>.

7


Figura 3: Enlace con objetivos

Otros estereotipos Las extensiones Web para UML están a punto de finalizarse en su fase inicial. Sin embargo, hay otros estereotipos que están bajo consideración como son <> o <>...

Consideraciones del proceso Una aplicación Web no es más que una especialización de un proceso cliente/servidor, con lo que se puede aprovechar el modelado de dichas aplicaciones. En particular, los casos de uso son una herramienta fundamental en la captura de requisitos. En el modelado, es importante tener en cuenta el que debemos empezar por las páginas cliente. En general, un caso de uso nos dará lugar a una página cliente distinta. Las páginas de servidor serán el último eslabón del proceso de producción, puesto que se generarán prácticamente ellas mismas al identificar los componentes del servidor y relacionarlos con las páginas cliente. Finalmente, es necesario considerar que se trata de un proceso abierto debido a los posibles cambios en el diseño y las extensiones propuestas, pero es una imagen clara y precisa de la aplicación Web.

Conclusión 8


El propósito principal del documento presente ha sido mostrar el diseño de aplicaciones Web con UML. Asumiendo que el modelado es importante y que deberíamos modelar los componentes de un sistema, descubrimos que un diseñador de aplicaciones Web deberá trabajar con páginas. Y puesto que UML está fundamentalmente orientado a objetos, no hay más remedio que descubrir los aspectos ocultos del modelado orientado a objetos que pueden presentar dichas páginas.

Bibliografía. www.conallen.com Whitepapers – modelling Web applications with UML.Modeling Web Application Architecture with UML Jim Conallen Comunication of ACM October 1999

9


MetodologiaUMLWeb

Recommend Documents