Aplicaciones Web con UML

Ricardo Marmolejo Garc a Ingenier del software a

Indice
1. Introduccin o 1.1. Qu es UML? . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 1.2. Patrn Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . . o 1.3. Sistema Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Evolucin de las metodolog Web o as 2.1. Entidad-Relacin . . . . . . . . . . . . . . . . . . . . . . . . . . . o 2.2. HDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 3 3 4 4 4 4 5 5 5 5 6 6 6 6 7

2.3. RMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. WebML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. WAE y WAE2 3.1. Tipos de estereotipos . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. En las entidades . . . . . . . . . . . . . . . . . . . . . . . 3.1.2. En las relaciones . . . . . . . . . . . . . . . . . . . . . . . 3.2. Diagramas de Componentes . . . . . . . . . . . . . . . . . . . . . 3.3. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . .

3.5. Eventos en el cliente . . . . . . . . . . . . . . . . . . . . . . . . .

4. Propuesta de metodolog gil a a 4.1. Diseo conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . n 4.2. Diseo grco, arb. de navegacin y base de datos . . . . . . . . n a o 4.3. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. Desarrollo grco y HTML . . . . . . . . . . . . . . . . . a 4.3.2. Desarrollo de lgica de negocio y base de datos . . . . . . o 4.3.3. Pruebas y benchmark . . . . . . . . . . . . . . . . . . . . 5. Conclusiones 6. Bibliograf a

7 7 7 8 8 8 8 9 9

1.

Introduccin o

Los sistemas web son relativamente nuevos en el mundo del computacin. Cao da vez son ms complejas y por tanto son un nuevo reto para los ingenieros a del software. Como el software, al principio no se modelaba1 , pronto surgen metodolog que intentan solucionar el problema. Un problema que se agraba as en los sistemas Web debido a que estos fomentan un entorno de requisitos muy cambiantes. Esto puede ser debido a un nmero de usuarios mundial que provou ca un gran nmero de requisitos. Adems el equipo de desarrolladores suele ser u a pequeo2 . n Los modelos son abstracciones que simplican nuestra comprensin de los siso 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 patrn o de diseo llamado MVC (modelo-vista-controlador). n

1.1.

Qu es UML? e

Bsicamente UML es un lenguaje estndar con un vocabulario grco y con a a a reglas para la presentacin de sistemas de informacin. Los Creadores : Grady o o Booch, Ivar Jacobson y James Rumbaugh3 . UML tiene distintos tipos de diagrama, dependiendo del concepto que queremos comunicar, usaremos un diagrama u otro. Parece que UML es insuciente semnticamente para Aplicaciones Web a (en principio).
1 Referente 2 Youtube

a la Crisis del software fue realizado en sus comienzos por 10 personas 3 Los tres amigos

1.2.

Patrn Modelo-Vista-Controlador o
4

El patrn MVC o

busca la programacin en 3 capas: o

Modelo: tienes los datos y su implementacin dene como se leen y eso 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 denen en esta capa al ser las ms abstractas son las a ms reutilizables. a Vista: o presentacin, es lo que ve el usuario. Ofrece al usuario los casos o de uso que el negocio ofrezca. Controlador: esta entre la Vista y el Modelo y une a ambos. Tambien llamado lgica de negocio, implementa la lgica de lo que le pasa a los o o modelos en funcin de los eventos que vienen de la Vista. o Algunos ejemplos de implementacin de MVC son Rails(Ruby), Structs(Java), o CakePHP,Kumbia,Symfony(PHP), TurboGears,Django(Python) ... etc. Los frameworks ms impactantes son Ruby on Rails y Django, estan orientados al desara rollo web eciente. Su objetivo es dar la opcin de base de datos. Creamos las o clase modelo y sus tables son creadas automaticamente, y actualizadas cuando modiquemos el modelo.

1.3.

Sistema Web

El servidor web ofrece pginas web y otos recursos (css, js, imagenes, ash ...) a Estos recursos se identican de forma unica mediante URL o URI. Los servidores web utilizan la comunicacin entre cliente y servidor utiliza el protocolo HTTP. o No mantiene conexin tras una peticin. Eso genera, que sea necesario recurrir a o o cookies para conocer el estado del cliente. (Sesiones) Una aplicacin web genera o una pgina web para un cliente en funcin de N variables. (diferenciar pgina a o a de aplicacin) Una aplicacin web es un sistema Web que nos ofrece la lgica o o o de negocio. (interfaces, formularios ...). Hace de frontend. Lenguajes en la parte del cliente Lenguajes de script como javascript (estndar ECMA), y Visual Baa sic Script(Microsoft). Pueden usarse para complementar la lgica de negocio. o Alivian al servidor. La web es sincrona pero la tendencia es la Web as ncrona gracias a un conjunto de tcnolog denominadas como AJAX. Para el rendere as izado Web se usa HTML, XHTML o XML. Complementados con CSS (hojas de estilo en cascada) Flash como lenguaje de presentacin. Aporta multimedia o a la web. Applet java ... Lenguajes en la parte del servidor Los ms conocidos a 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 patrn del software, no solo se usa en programacin Web o o

llegar a tener mezcladas las tres capas: presentacin(XHTML), lgica de negoo o cio(PHP) y modelo de datos(SQL). Procedimentales. La separacin de capas o es dicil ya que tradicionalmente la lgica de negocio se encarga de generar o la presentacin dinamicamente. En aplicaciones grandes, es preferible por usar o lenguajes que implementan MVC

2.

Evolucin de las metodolog Web o as

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

2.1.

Entidad-Relacin o

Aunque es un buen diagrama y podr ser necesario para toda aplicacin web, a o solo modela una parte del sistema, la capa del modelo de datos, si bien puede ser usado como complemento lo bueno ser buscar un unico lenguaje de modelado a que nos permitiera modelar todo y de forma ms integrada. Esto es as porque a sencillamente ER no fue diseado para el uso de modelado de aplicaciones Web. n

2.2.

HDM

Basado en el modelo E/R. El objetivo era crear un modelo que fuera de utilidad para realizar el diseo de una aplicacin de hipertexto. Es un intento de modelar n o la estructura del hipertexto-hipermedia, una modelizacin de las estructuras de o navegacin. Crear un modelo antes de desarrollar un hipertexto nos ayudar a o a conseguir una navegacin ms consistente y rica. En HDM la estructura de o a navegacin viene marcada por la estructura de datos. Fue en principio usado o para pginas estticas. a a

2.3.

RMM

Basado en E/R. Esta metodolog es apropiada para clases de objetos bien a denidas, y con claras relaciones entre esas clases Est orientada a problemas a con datos dinmicos que cambian con mucha frecuencia, ms que a entornos a a estticos como HDM Sin embargo, los mecanismos de acceso a la informacin a o son excesivamente simples y valen para un problema con pocas entidades, pero el modelo se queda corto si hay gran nmero de ellas. u

2.4.

WebML

En principio no coge nada de UML, aunque actualmente existen diagramas que los relacionan. Es una notacin visual para el diseo de aplicaciones Web compleo n jas que hacen uniso de datos intenso. Provee especicaciones grcas formales a para un proceso de diseo completo que puede ser asistido por herramientas n de diseo visuales. Tiene UNA herramienta comercial CASE orientada a jsp n (WebRatio). Realmente es un plugin de Eclipse. Estructura WebML Sitio = Estructura + Composicin + Navegacin + Presentacin o o o

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 ms barato hacer un estandar ampliando que a crendolo de cero. Lo primero que se plantea es que las aplicaciones Web prea sentan problemas que UML no contempla solucin. UML no facilita la tarea de o diferenciar cdigo cliente (scripts) de cdigo servidor. UML puede ser extendido o o para permitir una nueva semntica : estereotipos, listados de etiquetas(tags) y a restricciones(constraints): Estereotipos: dene una nueva semntica al modelo. a Lista de etiquetas: podemos entregar una lista de campo-valor. Restricciones : denen las reglas para trabajar con determinados estereotipos. Estereotipos en clases Dene los siguientes estereotipos para las entidades.

3.1.
3.1.1.

Tipos de estereotipos
En las entidades

Esto son los principales estereotipos que se denen: <<Server Page>> Son las pginas que contienen scripts o cdigo ejea o cutable por el servidor. (.php , .asp , .jsp) <<Client Page>> Son las pginas que estan en el lado del cliente, a normalmente pginas HTML y scripts (jsvascript). a <<Form>> Es la representacin de un formulario. Es cdigo HTML que o o contiene etiquetas de formulario como : <input>, <textarea>, <select> ... 5

Estos estereotipos se pueden ampliar con mucha exibilidad. Otros ejemplos de estereotipo pueden ser : <<Javascript>>, <<Applet>> o <<Flash>>. 3.1.2. En las relaciones

Dene los siguientes estereotipos para las relaciones: <<build>> Una relacin entre una pgina servidor y una pgina cliente. o a a La pgina servidor construye a la pgina cliente. a a <<link>> Es una relacin entre una pgina y otra pgina del sistema. o a a <<submit>> Es una relacin entre un formulario y un servidor de o pgina a

3.2.

Diagramas de Componentes

Ilustran las piezas del software que conformarn un sistema. Un componente a pueden ser un ejecutable, una librer esttica o dinmica, clases de Java, ... Un a a a 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 pgina de servidor genera una pgina de cliente, a a por ello server page y cliente page deberiamos de modelarlos agrupandolos como una componente, junto al resto de entidades, como objetos javascript, ash ...

3.3.

Casos de uso

Con especial incapie debemos tener en cuenta que tenemos visitantes de diferentes tipos y debe amos crear un tipo de actor en funcin del tipo de usuario. o 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 funcin del tiempo. Su uso respecto a UML no o cambia. En este diagrama se escriben las lineas de tiempo de los actores y componentes 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 echas 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 funcin. o

4.

Propuesta de metodolog gil a a

Se propone una metodolog gil basada en una propuesto de Ricardo Galli a a (un referente en el software libre, creador de meneame y bulma entre otros proyectos). Modicar esta metodolog para integrar UML en las fases de diseo. a n Tiene al menos 4 fases: 1. Diseo conceptual n 2. Diseo grco, arbol de navegacin y base de datos n a o 3. Desarrollo a) Desarrollo grco y HTML a b) Desarrollo de lgica de negocio y bases de datos o c) Pruebas y benchmark 4. Produccin o

4.1.

Dise o conceptual n

Inicialmente se realiza una entrevista al cliente, en busca de denir 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 diseo y funn cionalidad muy bsica. Es la llamada Proof of concept nos ayuda a convencer a al cliente y a tener un primer anlisis y diseo previo. a n

4.2.

Dise o grco, arb. de navegacin y base de datos n a o

Tras la abstraccin de requisitos que desea el cliente los diseadores gro n a cos deben ir comenzando con los bocetos basados en la prueba de concepto, los diseadores grcos deben comunicarse con los programadores, si bien un n a diseador no deben conocer la lgica si deben conocer las restricciones que le n o imponen el diseo. Mientras tanto los programadores pueden ir planteando los n diseos de aplicacin y base de datos. n o

4.3.

Desarrollo

Es recomendable realizar el desarrollo en varias fases: 4.3.1. Desarrollo grco y HTML a

No podemos exigir a un diseador conocimientos de programacin. Cada diseador n o n puede usar sus herramientas favoritas, siempre que cumpla el estandar y codicacin especicados por el proyecto. Por ejemplo, exigir que use un editor o con las siguientes caracter sticas: XHTML 1.0 Strict + UTF8. Los diseadores n crearn los grcos, y el cdigo HTML, en el contenido dinmico (contenido que a a o a vendra del modelo de datos) escribiern ejemplos. a Los programadores pueden hacer recomendaciones a los diseadores para evitar n problemas de integracin. Deben comentar las secciones del HTML, documentar o cada XPATH del CSS Validar la pgina por W3C durante el desarrollo grco a a (HTML , CSS , AAA ...). Algn consejo que se le suela dar a los diseadores : u n Es mejor no usar las caracter sticas ms novedosas de los navegadores(aunque es a discutible). Tener un criterio al nombrar las pginas acorde al modelo de datos. a Usar siempre rutas relativas para facilitir la migracin del proyecto. o Los diseadores deben preocuparse de la accesibilidad : UIML (User Intern face Markup Language) es un lenguaje de extensin del XML que promueve o la creacin de pginas web que puedan ser vistas en cualquier dispositivo coo a mo monitores para PC, telfonos o PDAs. Por problemas del visitante visuales, e 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 lgica de negocio y base de datos o

Al tiempo, los programadores van implementando la lgica y el modelo de datos, o harn sus pruebas con HTML muy simple. El proyecto deber estar en un reposa a itorio, con acceso remoto (SSH) en cualquier momento del d esto dar exa, a ibilidad de horario. Los diseadores deber terminar antes, estos modulos n an nalizados se ian integrando paulatinamente. r 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.

5.

Conclusiones
Se concluye que UML se puede ampliar al modelo web con componentes espec cos como las pginas, enlaces, cliente de scripts y otras formas a abstraccin y detalle adecuados para modeladores web. o 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 aplicaciones Web estan solventados por soluciones de Ingenier del Software. a El objeto de la ingenier del software se ha ampliado. a Los frameworks que ms impacto tienen hoy en d son Rails y Django. a a (Basados en MVC) Opinin personal : actualmente los sistemas web no se les exige tanta calo idad como en el software tradicional, esto unido a los grupos de desarrollo tan pequeos, hace que en los proyectos apenas se modele. Esto es algo n 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 expansion. 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.monograas.com/trabajos6/meto/meto.shtml Booch, G., Jacobson, I., Rumbaugh, J. The Unied Modeling Language Users Guide. Addison Wesley, Reading, MA, 1998 WebML: http://www10.org/paper-sample/html-sample.html