Uso de UML en aplicaciones Web: páginas y relaciones

Frecuentemente somos cuestionados en nuestros cursos acerca de las formas para representar de manera más explícita cierto tipo de aplicaciones utilizando UML, pero sin lo “aburrido” de la notación. Cierto es que UML es gráfico de por sí, pero usar los mismos elementos independientemente del tipo de aplicación, a algunas personas les genera ruido y prefieren algo más explícito. Por ejemplo cuando estudiamos el modelado de aplicaciones web, el modelado del negocio, de sistemas de tiempo real o de bases de datos con UML.

Para resolverlo aprovechamos una de las características peculiares que le dan flexibilidad a la notación de UML. Y consiste en el conjunto de mecanismos de extensión (de significado): estereotipo, restricción y valor etiquetado. Estos mecanismos le permiten a UML extender y enriquecer el significado de sus elementos y símbolos básico de tal suerte que pueden ser empleados para representar dominios en donde nunca se tuvo una intención explícita de origen de aplicarlos. Haberlo hecho así supondría una limitante para la aplicación genérica del lenguaje unificado. Ejemplos de estos dominios son el modelado de negocio (aunque ya existe BPMN como un estándar más específico), el modelado de bases de datos, el modelado de aplicaciones Web o el modelado de circuitos electrónicos, por mencionar algunos.

Arquitectura para web

La mayoría de las aplicaciones desarrolladas hoy en día son las aplicaciones llamadas Web, es decir, aquellas que tienen como elemento significativo de su arquitectura un navegador y un protocolo de comunicación HTTP. Cuando capacitamos a la gente en arquitectura y patrones, buscamos que el alumno comprenda las formas de elaborar este tipo de aplicaciones, como su ubicación en algunos de los patrones de arquitectura Web: “Cliente Delgado Web”, “Cliente Robusto Web” o “Reparto Web”.

El estándar de facto en WEB

En 1998, Jim Conallen definió una extensión a la que denominó WAE (Web Application Extension) para UML. Esta extensión es la convención más difundida y aceptada hasta nuestros días y podríamos decir que define el estándar de facto. En esta entrega, formada por dos artículos, presentaremos los elementos que definen el 20-80 en el modelado de aplicaciones Web usando la WAE. El foco de este artículo es la WAE en los diagrama de clases.

Extensiones WAE para el diagrama de Clases

Algunos de los ejemplos más comunes de estereotipos que se pueden asociar a las clases y a las relaciones entre estas, para representar una aplicación en web son las siguientes:

Estereotipos para las Clases
Estereotipo Descripción

Server Page
Representa una página Web que tiene scripts ejecutados por el servidor. Estos scripts interactúan con los recursos que se encuentran al alcance del servidor. Sólo puede mantener relaciones con objetos que se encuentren en el servidor

Client Page
Representan páginas que son dibujadas por el navegador web y pueden ser una combinación de algún o algunos lenguajes de marcado, scripts del lado del cliente, islas de datos, etc.

Form
Representa una colección de campos de entrada que forman parte con una página del lado cliente (Client Page). Tiene una correspondencia directa con la etiqueta <FORM> de XHTML.

ClientScript Object
Es una colección de scripts del lado del cliente que existe como un archivo separado y que son incluidos mediante una petición independiente por parte del navegador.
Estereotipos para las Relaciones entre las Clases
Link Representa un apuntador desde una “client page” hacia una “client page” o “server page”. Corresponde directamente con una etiqueta <a> (ancla) de HTML
Submit Esta relación siempre se da entre una “form” y una “server page”, por supuesto, la “server page” procesa los datos que la “form” le envía (submits)
Build Sirve para identificar cuales “server page” son responsables de de la creación de una “client page”. Una “server page” puede crear varias “client page”, pero una “client page” sólo puede ser creada por una sola “server page”. Esta relación siempre es unidireccional
Redirect Esta es también una relación unidireccional que indica que una página Web redirige hacia otra. En caso de que la página origen sea una “client page” esta asociación corresponderá con la “META” etiqueta y valor HTTP-EQUIV de “Refresh”*.


Un ejemplo de sistema en Web

Si bien no presentaremos el modelo de casos de uso para ejemplificar el uso de esta notación, para resaltar el modelo de clases con sus extensiones, si necesitamos ubicar el ejemplo en algún escenario. Por ejemplo: en nuestro sitio nuestros alumnos pueden consultar los datos del curso en el que están inscritos y, desde este mismo lugar, pueden también contestar una encuesta de satisfacción durante el último día del mismo. En la Figura 1 vemos parte del modelo de clases de dicho sistema utilizando los estereotipos propios de WAE.

Anotaciones básicas

Suponemos que está de más comentar que las relaciones entre las clases en los diagramas de clases no sugieren o asumen ningún tipo de flujo, que las puntas de flechas sólo son restricciones en cuanto al sentido en que la relación puede ser transitada. Recordemos que el diagrama de clases es un diagrama estructural. También cabe señalar que el diagrama de clases que aquí se presenta tiene un punto de vista de diseño y no uno conceptual (Figura 1).
Nombres o iconos

Igual que cuando brindamos nuestra capacitación presencial, y antes de analizar este modelo de clases, consideramos conveniente recordarle a nuestro público que algunos elementos estereotipados cuentan con iconos alternativos que pueden utilizarse, aunque esto es algo opcional. En nuestro ejemplo se muestran directamente los nombres de los estereotipos para cada clase y relación, en lugar de los iconos asociados a cada uno de esos estereotipos. Muchas herramientas de modelado te permiten, de manera simple, elegir entre una u otra forma de representación.


Figura 1: Modelo de sistema de cursos y encuestas con extensiones WAE

Aplicación de WAE en las páginas

En el diagrama de la Figura 1 podemos observar varias clases a las que se les han asociado los estereotipos antes descritos, también podemos observar que entre las clases sólo existen relaciones de asociación, de las cuales algunas usan los estereotipos WAE y otras no. Las que no usan los estereotipos WAE como por ejemplo la relación entre “LoginForm” y “LoginValidator” es la veterana relación de composición, la cual indica lo de siempre, que el script del lado del cliente “LoginValidator” es una pieza inseparable de la forma “LoginForm”.

Relaciones WAE entre las páginas del sistema

También podemos ver que la página del lado del servidor “PresentarDatosCurso” es la responsable de procesar los datos que la forma “Login” le envía (relación «submit»). Otra de las cosas que podemos ver es que la página del lado del servidor “PresentarDatosCurso” es la que se encarga de construir la página del lado del cliente “CursoForm” (relación «build») o, en caso de presentarse un error, redirigir el control a la página del lado del servidor que se encarga de manejarlo “ReportarError” (relación «redirect»). Finalmente, podemos notar también que la página del lado del cliente “CursoForm” mantiene una liga hacia la página del lado del servidor “EncuestaParticipante” (relación «link»).

Sólo el comienzo

Existen algunos otros elementos definidos en la WAE que aquí hemos omitido. Este artículo presenta sólo unos pocos de los más utilizados. Próximamente presentaremos los estereotipos y aplicación de estos en los diagramas de componentes; y recuerda que al elaborar tus modelos, en muchos casos, entre más simple mejor. Al fin y al cabo un modelo busca simplificar, no complicar las cosas.


 

Ver más artículos

Póliza Abiztar Plus

Descubre aquí todos los beneficios de La Póliza Abiztar Plus.

Garantía Universal

Los ambientes ubicuos de aprendizaje Abiztar, incluyen Garantía Universal. ¿Qué es esto?

Información general
Conoce la Póliza Abiztar Plus
Recomendaciones de capacitación
Calendario de cursos

Base de conocimiento
UML y Arquitecturas
Administración de Proyectos
Procesos de Software
Artículos

Contáctanos

Teléfono en México D.F. - +52 (55) 5594 6411 / E-mail: cursos@abiztar.com.mx

O si lo prefieres llena el formulario de contacto

Ver aviso de privacidad

© Abiztar. PMI, PMBOK Guide, OPM3, CAPM, PMP, PMI-SP y PMI-RMP son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. Capability Maturity Model y CMM son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon. CMM, IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. MDA, BPMN, SysML, MOF, OMG y UML son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP es una marca registrada por IBM Corp."