Modelado de aplicaciones Web mediante UML

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
Sitios Web
1
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
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.
Formas
2
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
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
Con los componentes ya mencionados, se puede desarrollar una buena
Aplicación Web, aunque otros componentes más recientes pueden afectar su
3
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
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 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
4
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
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 cliente hacia otra
de su misma clase. Si dicho enlace contiene parámetros, se modelan fuera de
la relación.
5
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
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
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
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
7
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia
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
8
Laboratorio de Sistemas de Información
Facultad de Informática
Universidad Politécnica de Valencia