Aplicaciones Web con UML

Ricardo Marmolejo Garca

Ingeniera del software

Indice
1. Introduccion 2
1.1. Que es UML? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Patron Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . . 3
1.3. Sistema Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Evolucion de las metodologas Web 4

2.1. Entidad-Relacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 metodologa agil 7
4.1. Diseno conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Diseno grafico, arb. de navegacion y base de datos . . . . . . . . 7
4.3. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Desarrollo grafico y HTML . . . . . . . . . . . . . . . . . 8
4.3.2. Desarrollo de logica de negocio y base de datos . . . . . . 8
4.3.3. Pruebas y benchmark . . . . . . . . . . . . . . . . . . . . 8

5. Conclusiones 9

6. Bibliografa 9

1. Introduccion
Los sistemas web son relativamente nuevos en el mundo del computacion. Ca-
da vez son mas complejas y por tanto son un nuevo reto para los ingenieros
del software. Como el software, al principio no se modelaba1 , pronto surgen
metodologas 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 numero de usuarios mundial que provo-
ca un gran numero de requisitos. Ademas el equipo de desarrolladores suele ser
pequeno2 .
Los modelos son abstracciones que simplifican nuestra comprension 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 patron
de diseno llamado MVC (modelo-vista-controlador).

1.1. Que es UML?

Basicamente UML es un lenguaje estandar con un vocabulario grafico y con

reglas para la presentacion de sistemas de informacion. 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 semanticamente 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. Patron Modelo-Vista-Controlador
4
El patron MVC busca la programacion en 3 capas:

Modelo: tienes los datos y su implementacion define como se leen y es-

criben esos datos. Tipicamente hace querys a una BDD, pero esto podra
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 mas abstractas son las
mas reutilizables.

Vista: o presentacion, 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 logica de negocio, implementa la logica de lo que le pasa a los
modelos en funcion de los eventos que vienen de la Vista.

Algunos ejemplos de implementacion de MVC son Rails(Ruby), Structs(Java),

CakePHP,Kumbia,Symfony(PHP), TurboGears,Django(Python) ... etc. Los frame-
works mas impactantes son Ruby on Rails y Django, estan orientados al desar-
rollo web eficiente. Su objetivo es dar la opcion 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 paginas web y otos recursos (css, js, imagenes, flash ...)
Estos recursos se identifican de forma unica mediante URL o URI. Los servidores
web utilizan la comunicacion entre cliente y servidor utiliza el protocolo HTTP.
No mantiene conexion tras una peticion. Eso genera, que sea necesario recurrir a
cookies para conocer el estado del cliente. (Sesiones) Una aplicacion web genera
una pagina web para un cliente en funcion de N variables. (diferenciar pagina
de aplicacion) Una aplicacion web es un sistema Web que nos ofrece la logica
de negocio. (interfaces, formularios ...). Hace de frontend. Lenguajes en la parte
del cliente Lenguajes de script como javascript (estandar ECMA), y Visual Ba-
sic Script(Microsoft). Pueden usarse para complementar la logica de negocio.
Alivian al servidor. La web es sincrona pero la tendencia es la Web asncrona
gracias a un conjunto de tecnologas 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 presentacion. Aporta multimedia
a la web. Applet java ... Lenguajes en la parte del servidor Los mas 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 patron del software, no solo se usa en programacion Web

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

2. Evolucion de las metodologas Web

A continuacion voy a explicar alguna (no todas), las metodologas/diagramas o
modelos que tratan de solucionar el modelado web:

2.1. Entidad-Relacion

Aunque es un buen diagrama y podra ser necesario para toda aplicacion web,
solo modela una parte del sistema, la capa del modelo de datos, si bien puede ser
usado como complemento lo bueno sera buscar un unico lenguaje de modelado
que nos permitiera modelar todo y de forma mas integrada. Esto es as porque
sencillamente ER no fue disenado 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 diseno de una aplicacion de hipertexto. Es un intento de modelar
la estructura del hipertexto-hipermedia, una modelizacion de las estructuras de
navegacion. Crear un modelo antes de desarrollar un hipertexto nos ayudara a
conseguir una navegacion mas consistente y rica. En HDM la estructura de
navegacion viene marcada por la estructura de datos. Fue en principio usado
para paginas estaticas.

2.3. RMM

Basado en E/R. Esta metodologa es apropiada para clases de objetos bien

definidas, y con claras relaciones entre esas clases Esta orientada a problemas
con datos dinamicos que cambian con mucha frecuencia, mas que a entornos
estaticos como HDM Sin embargo, los mecanismos de acceso a la informacion
son excesivamente simples y valen para un problema con pocas entidades, pero
el modelo se queda corto si hay gran numero de ellas.

4
2.4. WebML

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

los relacionan. Es una notacion visual para el diseno de aplicaciones Web comple-
jas que hacen uniso de datos intenso. Provee especificaciones graficas formales
para un proceso de diseno completo que puede ser asistido por herramientas
de diseno visuales. Tiene UNA herramienta comercial CASE orientada a jsp
(WebRatio). Realmente es un plugin de Eclipse. Estructura WebML Sitio =
Estructura + Composicion + Navegacion + Presentacion

3. WAE y WAE2
Es el unico 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 mas barato hacer un estandar ampliando que
creandolo de cero. Lo primero que se plantea es que las aplicaciones Web pre-
sentan problemas que UML no contempla solucion. UML no facilita la tarea de
diferenciar codigo cliente (scripts) de codigo servidor. UML puede ser extendido
para permitir una nueva semantica : estereotipos, listados de etiquetas(tags) y
restricciones(constraints):

Estereotipos: define una nueva semantica 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 paginas que contienen scripts o codigo eje-
cutable por el servidor. (.php , .asp , .jsp)
<<Client Page>> Son las paginas que estan en el lado del cliente,
normalmente paginas HTML y scripts (jsvascript).
<<Form>> Es la representacion de un formulario. Es codigo 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 relacion entre una pagina servidor y una pagina cliente.
La pagina servidor construye a la pagina cliente.

<<link>> Es una relacion entre una pagina y otra pagina del sistema.
<<submit>> Es una relacion entre un formulario y un servidor de
pagina

3.2. Diagramas de Componentes

Ilustran las piezas del software que conformaran un sistema. Un componente

pueden ser un ejecutable, una librera estatica o dinamica, 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 pagina de servidor genera una pagina 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 debeamos crear un tipo de actor en funcion 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 funcion 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 tecnologa
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 funcion.

4. Propuesta de metodologa agil

Se propone una metodologa agil basada en una propuesto de Ricardo Galli
(un referente en el software libre, creador de meneame y bulma entre otros
proyectos). Modificar esta metodologa para integrar UML en las fases de diseno.
Tiene al menos 4 fases:

1. Diseno conceptual

2. Diseno grafico, arbol de navegacion y base de datos

3. Desarrollo

a) Desarrollo grafico y HTML

b) Desarrollo de logica de negocio y bases de datos
c) Pruebas y benchmark

4. Produccion

4.1. Diseno 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 diseno y fun-
cionalidad muy basica. Es la llamada Proof of concept nos ayuda a convencer
al cliente y a tener un primer analisis y diseno previo.

4.2. Diseno grafico, arb. de navegacion y base de datos

Tras la abstraccion de requisitos que desea el cliente los disenadores grafi-

cos deben ir comenzando con los bocetos basados en la prueba de concepto,
los disenadores graficos deben comunicarse con los programadores, si bien un
disenador no deben conocer la logica si deben conocer las restricciones que le
imponen el diseno. Mientras tanto los programadores pueden ir planteando los
disenos de aplicacion y base de datos.

7
4.3. Desarrollo

Es recomendable realizar el desarrollo en varias fases:

4.3.1. Desarrollo grafico y HTML

No podemos exigir a un disenador conocimientos de programacion. Cada disenador

puede usar sus herramientas favoritas, siempre que cumpla el estandar y cod-
ificacion especificados por el proyecto. Por ejemplo, exigir que use un editor
con las siguientes caractersticas: XHTML 1.0 Strict + UTF8. Los disenadores
crearan los graficos, y el codigo HTML, en el contenido dinamico (contenido que
vendra del modelo de datos) escribieran ejemplos.
Los programadores pueden hacer recomendaciones a los disenadores para evitar
problemas de integracion. Deben comentar las secciones del HTML, documentar
cada XPATH del CSS Validar la pagina por W3C durante el desarrollo grafico
(HTML , CSS , AAA ...). Algun consejo que se le suela dar a los disenadores :
Es mejor no usar las caractersticas mas novedosas de los navegadores(aunque es
discutible). Tener un criterio al nombrar las paginas acorde al modelo de datos.
Usar siempre rutas relativas para facilitir la migracion del proyecto.
Los disenadores deben preocuparse de la accesibilidad : UIML (User Inter-
face Markup Language) es un lenguaje de extension del XML que promueve
la creacion de paginas web que puedan ser vistas en cualquier dispositivo co-
mo monitores para PC, telefonos 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 logica de negocio y base de datos

Al tiempo, los programadores van implementando la logica y el modelo de datos,

haran sus pruebas con HTML muy simple. El proyecto debera estar en un repos-
itorio, con acceso remoto (SSH) en cualquier momento del da, esto dara flex-
ibilidad de horario. Los disenadores deberan terminar antes, estos modulos
finalizados se iran 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 poltica 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
especficos como las paginas, enlaces, cliente de scripts y otras formas
abstraccion 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 Ingeniera del Software.
El objeto de la ingeniera del software se ha ampliado.

Los frameworks que mas impacto tienen hoy en da son Rails y Django.
(Basados en MVC)
Opinion 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 pequenos, 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. Bibliografa
[ 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