182000

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 desarrollo de Internet, el comercio electrónico y 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 necesario
un modelado capaz de recoger y mostrar todas las estructuras, formas y
componentes presentes en el 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 desarrollo
provoca, a veces, la ausencia de un análisis y diseño correctos, pero están
consiguiendo reemplazar a las aplicaciones software tradicionales. Lo que aquí
vamos a ver es una 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, veremos la
arquitectura de dichas aplicaciones. A continuació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.

Arquitectura de una Aplicación Web
1
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia

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.

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.

2

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.
Figura 2 : estructura de una página Web

Otros Componentes

3

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 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
4

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 <<método de cliente >> 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
• 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 <<construye>>. 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 <<redirige>>. 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. <<presenciar>>. Es algo más sutil que los anteriores y se sumaría a un
diagrama que ya conste de un estereotipo <<construye>>. 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
<<enlace>>. 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
5

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
<<componente servidor>> o <<componente cliente>>, para poder diferenciar
quién puede servirse de ellos.

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 <<forma>> que a su vez
va a generarnos otro nuevo: <<envía>>. 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
<<marcos>>.
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: <<objetivo>>.
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 <<enlace con objetivo>>.

6

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 <<xml>> o <<scriplet>>...

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

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
7

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

8

182000

Más contenido relacionado

La actualidad más candente

Destacado

Similar a 182000

182000