Aplicaciones Web con UML

Ricardo Marmolejo Garcı́a

Ingenierı́a del software

Índice
1. Introducción 2
1.1. ¿Qué es UML? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Patrón Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . . 3
1.3. Sistema Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Evolución de las metodologı́as Web 4

2.1. Entidad-Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. HDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. RMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. WebML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3. WAE y WAE2 5
3.1. Tipos de estereotipos . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. En las entidades . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. En las relaciones . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Diagramas de Componentes . . . . . . . . . . . . . . . . . . . . . 6
3.3. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Eventos en el cliente . . . . . . . . . . . . . . . . . . . . . . . . . 7

1
4. Propuesta de metodologı́a ágil 7
4.1. Diseño conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Diseño gráfico, arb. de navegación y base de datos . . . . . . . . 7
4.3. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Desarrollo gráfico y HTML . . . . . . . . . . . . . . . . . 8
4.3.2. Desarrollo de lógica de negocio y base de datos . . . . . . 8
4.3.3. Pruebas y benchmark . . . . . . . . . . . . . . . . . . . . 8

5. Conclusiones 9

6. Bibliografı́a 9

1. Introducción
Los sistemas web son relativamente nuevos en el mundo del computación. Ca-
da vez son más complejas y por tanto son un nuevo reto para los ingenieros
del software. Como el software, al principio no se modelaba1 , pronto surgen
metodologı́as que intentan solucionar el problema. Un problema que se agraba
en los sistemas Web debido a que estos fomentan un entorno de requisitos muy
cambiantes. Esto puede ser debido a un número de usuarios mundial que provo-
ca un gran número de requisitos. Además el equipo de desarrolladores suele ser
pequeño2 .
Los modelos son abstracciones que simplifican nuestra comprensión de los sis-
temas. Como lenguaje de modelado ya existente deberiamos considerar si UML
tiene capacidad para modelar en aplicaciones Web. Veremos queremos que Jim
Conallen recomienda modelar webs extediendo UML y aplicacando un patrón
de diseño llamado MVC (modelo-vista-controlador).

1.1. ¿Qué es UML?

Básicamente UML es un lenguaje estándar con un vocabulario gráfico y con

reglas para la presentación de sistemas de información. Los Creadores : Grady
Booch, Ivar Jacobson y James Rumbaugh3 . UML tiene distintos tipos de diagra-
ma, dependiendo del concepto que queremos comunicar, usaremos un diagrama
u otro. Parece que UML es insuficiente semánticamente para Aplicaciones Web
(en principio).
1 Referente a la Crisis del software
2 Youtube fue realizado en sus comienzos por 10 personas
3 Los tres amigos

2
1.2. Patrón Modelo-Vista-Controlador
4
El patrón MVC busca la programación en 3 capas:

Modelo: tienes los datos y su implementación define como se leen y es-

criben esos datos. Tipicamente hace querys a una BDD, pero esto podrı́a
ser un sistema de archivos, o un banco que nos provee datos por XML.
Las clases que se definen en esta capa al ser las más abstractas son las
más reutilizables.

Vista: o presentación, es lo que ve el usuario. Ofrece al usuario los casos

de uso que el negocio ofrezca.
Controlador: esta entre la Vista y el Modelo y une a ambos. Tambien
llamado lógica de negocio, implementa la lógica de lo que le pasa a los
modelos en función de los eventos que vienen de la Vista.

Algunos ejemplos de implementación de MVC son Rails(Ruby), Structs(Java),

CakePHP,Kumbia,Symfony(PHP), TurboGears,Django(Python) ... etc. Los frame-
works más impactantes son Ruby on Rails y Django, estan orientados al desar-
rollo web eficiente. Su objetivo es dar la opción de base de datos. Creamos las
clase modelo y sus tables son creadas automaticamente, y actualizadas cuando
modifiquemos el modelo.

1.3. Sistema Web

El servidor web ofrece páginas web y otos recursos (css, js, imagenes, flash ...)
Estos recursos se identifican de forma única mediante URL o URI. Los servidores
web utilizan la comunicación entre cliente y servidor utiliza el protocolo HTTP.
No mantiene conexión tras una petición. Eso genera, que sea necesario recurrir a
cookies para conocer el estado del cliente. (Sesiones) Una aplicación web genera
una página web para un cliente en función de N variables. (diferenciar página
de aplicación) Una aplicación web es un sistema Web que nos ofrece la lógica
de negocio. (interfaces, formularios ...). Hace de frontend. Lenguajes en la parte
del cliente Lenguajes de script como javascript (estándar ECMA), y Visual Ba-
sic Script(Microsoft). Pueden usarse para complementar la lógica de negocio.
Alivian al servidor. La web es sincrona pero la tendencia es la Web ası́ncrona
gracias a un conjunto de técnologı́as denominadas como AJAX. Para el render-
izado Web se usa HTML, XHTML o XML. Complementados con CSS (hojas
de estilo en cascada) Flash como lenguaje de presentación. Aporta multimedia
a la web. Applet java ... Lenguajes en la parte del servidor Los más conocidos
son PHP(software libre), JSP (Sun Microsystems) y ASP/ASP.NET(Microsoft)
Las primeras versiones de PHP y ASP no separaban bien las capas. Pudiendo
4 Es un patrón del software, no solo se usa en programación Web

3
llegar a tener mezcladas las tres capas: presentación(XHTML), lógica de nego-
cio(PHP) y modelo de datos(SQL). Procedimentales. La separación de capas
es dificil ya que tradicionalmente la lógica de negocio se encarga de generar
la presentación dinamicamente. En aplicaciones grandes, es preferible por usar
lenguajes que implementan MVC

2. Evolución de las metodologı́as Web

A continuación voy a explicar alguna (no todas), las metodologı́as/diagramas o
modelos que tratan de solucionar el modelado web:

2.1. Entidad-Relación

Aunque es un buen diagrama y podrı́a ser necesario para toda aplicación web,
solo modela una parte del sistema, la capa del modelo de datos, si bien puede ser
usado como complemento lo bueno serı́a buscar un único lenguaje de modelado
que nos permitiera modelar todo y de forma más integrada. Esto es ası́ porque
sencillamente ER no fue diseñado para el uso de modelado de aplicaciones Web.

2.2. HDM

Basado en el modelo E/R. El objetivo era crear un modelo que fuera de utilidad
para realizar el diseño de una aplicación de hipertexto. Es un intento de modelar
la estructura del hipertexto-hipermedia, una modelización de las estructuras de
navegación. Crear un modelo antes de desarrollar un hipertexto nos ayudará a
conseguir una navegación más consistente y rica. En HDM la estructura de
navegación viene marcada por la estructura de datos. Fue en principio usado
para páginas estáticas.

2.3. RMM

Basado en E/R. Esta metodologı́a es apropiada para clases de objetos bien

definidas, y con claras relaciones entre esas clases Está orientada a problemas
con datos dinámicos que cambian con mucha frecuencia, más que a entornos
estáticos como HDM Sin embargo, los mecanismos de acceso a la información
son excesivamente simples y valen para un problema con pocas entidades, pero
el modelo se queda corto si hay gran número de ellas.

4
2.4. WebML

En principio no coge nada de UML, aunque actualmente existen diagramas que

los relacionan. Es una notación visual para el diseño de aplicaciones Web comple-
jas que hacen uniso de datos intenso. Provee especificaciones gráficas formales
para un proceso de diseño completo que puede ser asistido por herramientas
de diseño visuales. Tiene UNA herramienta comercial CASE orientada a jsp
(WebRatio). Realmente es un plugin de Eclipse. Estructura WebML Sitio =
Estructura + Composición + Navegación + Presentación

3. WAE y WAE2
Es el único exclusivamente basado en UML. Ha sido desarrollado por Jim
Conallen, empleado de Rational Software Corporation. WAE como UML es
recomendado usarlo en lenguajes orientados a objetos. Jim opta por ampliar
UML sencillamente porque es más barato hacer un estandar ampliando que
creándolo de cero. Lo primero que se plantea es que las aplicaciones Web pre-
sentan problemas que UML no contempla solución. UML no facilita la tarea de
diferenciar código cliente (scripts) de código servidor. UML puede ser extendido
para permitir una nueva semántica : estereotipos, listados de etiquetas(tags) y
restricciones(constraints):

Estereotipos: define una nueva semántica al modelo.

Lista de etiquetas: podemos entregar una lista de campo-valor.
Restricciones : definen las reglas para trabajar con determinados estereoti-
pos. Estereotipos en clases Define los siguientes estereotipos para las en-
tidades.

3.1. Tipos de estereotipos

3.1.1. En las entidades

Esto son los principales estereotipos que se definen:

<<Server Page>> Son las páginas que contienen scripts o código eje-
cutable por el servidor. (.php , .asp , .jsp)
<<Client Page>> Son las páginas que estan en el lado del cliente,
normalmente páginas HTML y scripts (jsvascript).
<<Form>> Es la representación de un formulario. Es código HTML que
contiene etiquetas de formulario como : <input>, <textarea>, <select>
...

5
Estos estereotipos se pueden ampliar con mucha flexibilidad. Otros ejemplos de
estereotipo pueden ser : <<Javascript>>, <<Applet>> o <<Flash>>.

3.1.2. En las relaciones

Define los siguientes estereotipos para las relaciones:

<<build>> Una relación entre una página servidor y una página cliente.
La página servidor ”construye” a la página cliente.

<<link>> Es una relación entre una página y otra página del sistema.
<<submit>> Es una relación entre un formulario y un servidor de
página

3.2. Diagramas de Componentes

Ilustran las piezas del software que conformarán un sistema. Un componente

pueden ser un ejecutable, una librerı́a estática o dinámica, clases de Java, ... Un
componente abstrae un conjunto de clases para que pueda el componente ser
utilizado como una unidad, esto es el API que todo componente debe proveer. Su
funcionamiento es igual que con UML 2.0. En WAE normalmente se utiliza para
abstraer el hecho de que una página de servidor genera una página de cliente,
por ello server page y cliente page deberiamos de modelarlos agrupandolos como
una componente, junto al resto de entidades, como objetos javascript, flash ...

3.3. Casos de uso

Con especial incapie debemos tener en cuenta que tenemos visitantes de difer-
entes tipos y debeı́amos crear un tipo de actor en función del tipo de usuario.
Por ejemplo : En el formulario de registro le preguntamos si se considera un
usuario avanzado o no.

3.4. Diagrama de secuencia

Explica los casos de uso en función del tiempo. Su uso respecto a UML no
cambia. En este diagrama se escriben las lineas de tiempo de los actores y com-
ponentes implicadas. Los actores y componentes se envian mensajes entre ellos
describiendo los problemas del sistema. Las paginas del cliente pueden enviarse
mensajes a si mismo (funciones javascript donde el servidor no interviene) pero
si vemos flechas asincronas que van desde el cliente hasta el servidor solo pueden
ser interpretadas por el programador como el uso de AJAX, ya que la tecnologı́a
web es sincrona.

6
3.5. Eventos en el cliente

Los eventos de cliente (eventos de javascript como onClick , onLoad, etc ...)
pueden ser representados en las listas de etiquetas donde el campo es el nombre
del evento y el valor es el nombre de la función.

4. Propuesta de metodologı́a ágil

Se propone una metodologı́a ágil basada en una propuesto de Ricardo Galli
(un referente en el software libre, creador de meneame y bulma entre otros
proyectos). Modificar esta metodologı́a para integrar UML en las fases de diseño.
Tiene al menos 4 fases:

1. Diseño conceptual

2. Diseño gráfico, arbol de navegación y base de datos

3. Desarrollo

a) Desarrollo gráfico y HTML

b) Desarrollo de lógica de negocio y bases de datos
c) Pruebas y benchmark

4. Producción

4.1. Diseño conceptual

Inicialmente se realiza una entrevista al cliente, en busca de definir los requisitos

correctos. Como se navegara, tipos de cliente al que va dirigido, nivel cultural de
los visitantes. Se pueden presentar una ”prueba de concepto” de diseño y fun-
cionalidad muy básica. Es la llamada ”Proof of concept” nos ayuda a convencer
al cliente y a tener un primer análisis y diseño previo.

4.2. Diseño gráfico, arb. de navegación y base de datos

Tras la abstracción de requisitos que desea el cliente los diseñadores gráfi-

cos deben ir comenzando con los bocetos basados en la prueba de concepto,
los diseñadores gráficos deben comunicarse con los programadores, si bien un
diseñador no deben conocer la lógica si deben conocer las restricciones que le
imponen el diseño. Mientras tanto los programadores pueden ir planteando los
diseños de aplicación y base de datos.

7
4.3. Desarrollo

Es recomendable realizar el desarrollo en varias fases:

4.3.1. Desarrollo gráfico y HTML

No podemos exigir a un diseñador conocimientos de programación. Cada diseñador

puede usar sus herramientas favoritas, siempre que cumpla el estandar y cod-
ificación especificados por el proyecto. Por ejemplo, exigir que use un editor
con las siguientes caracterı́sticas: XHTML 1.0 Strict + UTF8. Los diseñadores
crearán los gráficos, y el código HTML, en el contenido dinámico (contenido que
vendra del modelo de datos) escribierán ejemplos.
Los programadores pueden hacer recomendaciones a los diseñadores para evitar
problemas de integración. Deben comentar las secciones del HTML, documentar
cada XPATH del CSS Validar la página por W3C durante el desarrollo gráfico
(HTML , CSS , AAA ...). Algún consejo que se le suela dar a los diseñadores :
Es mejor no usar las caracterı́sticas más novedosas de los navegadores(aunque es
discutible). Tener un criterio al nombrar las páginas acorde al modelo de datos.
Usar siempre rutas relativas para facilitir la migración del proyecto.
Los diseñadores deben preocuparse de la accesibilidad : UIML (User Inter-
face Markup Language) es un lenguaje de extensión del XML que promueve
la creación de páginas web que puedan ser vistas en cualquier dispositivo co-
mo monitores para PC, teléfonos o PDAs. Por problemas del visitante visuales,
motrices, auditivas o cognitivas. La W3C investiga una rama llamada WAI vela
por la accesibilidad con 3 niveles, A, AA y AAA. Existe software que mide la
accesibilidad (TAW, HERA ...)

4.3.2. Desarrollo de lógica de negocio y base de datos

Al tiempo, los programadores van implementando la lógica y el modelo de datos,

harán sus pruebas con HTML muy simple. El proyecto deberı́a estar en un repos-
itorio, con acceso remoto (SSH) en cualquier momento del dı́a, esto dará flex-
ibilidad de horario. Los diseñadores deberı́an terminar antes, estos modulos
finalizados se iŕan integrando paulatinamente.

4.3.3. Pruebas y benchmark

Si tenemos un producto funcional se puede ir mostrando al cliente y pedirle que

haga pruebas y revise requisitos. Las pruebas dependiendo de la polı́tica de la
empresa puden realizarse online, incluso con la ayuda del cliente.
Las pruebas de benchmark deben arrojar un resultado funcional.

8
5. Conclusiones
Se concluye que UML se puede ampliar al modelo web con componentes
especı́ficos como las páginas, enlaces, cliente de scripts y otras formas
abstracción y detalle adecuados para modeladores web.
Debido a la complejidad de los sistemas Web es necesario modelar. Con
UML o con otras formas de modelado.
Actualmente los problemas de mantenibilidad y escalabilidad de las apli-
caciones Web estan solventados por soluciones de Ingenierı́a del Software.
El objeto de la ingenierı́a del software se ha ampliado.

Los frameworks que más impacto tienen hoy en dı́a son Rails y Django.
(Basados en MVC)
Opinión personal : actualmente los sistemas web no se les exige tanta cal-
idad como en el software tradicional, esto unido a los grupos de desarrollo
tan pequeños, hace que en los proyectos apenas se modele. Esto es algo
que veo desde mi punto de vista, y tambien siento que va cambiar, se va (y
debe) a ir exigiendo mas calidad. Algunos de los argumentos que me hacen
pensar asi : Son las eternas betas de google, productos en continua expan-
sion. En cierto sentido la web esta mas viva que un software de escritorio,
esto hace que se tienda a pensar que ese fallo que hemos encontrado “ya
lo arreglaran”. Por mucho que las empresas nos traten de acostumbrar a
la falta de calidad y al concepto de beta mal entendido, no conseguiran
nada, ya que el usuario quiere calidad ya sea en la web o en el escritorio.

6. Bibliografı́a
[ Conallen, 1998 ] Conallen, Jim. “Modeling Web Application Design with UML”
Presentation – Conallen, Inc. http://www.rational.com/media/whitepapers/webapps.pdf
Junio, 1998.
Ricardo Galli : http://bulma.net/body.phtml?nIdNoticia=734
http://gallir.wordpress.com/2008/04/16/disenos-ingenieria-agiles-y-frameworks/
HDM : http://www.hipertexto.info/documentos/hdm.htm
OMT : http://www.monografias.com/trabajos6/meto/meto.shtml
Booch, G., Jacobson, I., Rumbaugh, J. The Unified Modeling Language Users
Guide. Addison Wesley, Reading, MA, 1998
WebML: http://www10.org/paper-sample/html-sample.html