Aplicaciones Web con UML

Ricardo Marmolejo Garc a Ingenier a del software

Indice
1. Introducci on 1.1. Qu e es UML? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Patr on Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . . 1.3. Sistema Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Evoluci on de las metodolog as Web 2.1. Entidad-Relaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 a agil 4.1. Dise no conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Dise no gr aco, arb. de navegaci on y base de datos . . . . . . . . 4.3. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. Desarrollo gr aco y HTML . . . . . . . . . . . . . . . . . 4.3.2. Desarrollo de l ogica de negocio y base de datos . . . . . . 4.3.3. Pruebas y benchmark . . . . . . . . . . . . . . . . . . . . 5. Conclusiones 6. Bibliograf a

7 7 7 8 8 8 8 9 9

1.

Introducci on

Los sistemas web son relativamente nuevos en el mundo del computaci on. Cada vez son m as 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 umero de usuarios mundial que provoca un gran n umero de requisitos. Adem as el equipo de desarrolladores suele ser peque no2 . Los modelos son abstracciones que simplican nuestra comprensi on de los sistemas. 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 on de dise no llamado MVC (modelo-vista-controlador).

1.1.

Qu e es UML?

B asicamente UML es un lenguaje est andar con un vocabulario gr aco y con reglas para la presentaci on de sistemas de informaci on. Los Creadores : Grady 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 sem anticamente para Aplicaciones Web (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.

Patr on Modelo-Vista-Controlador
4

El patr on MVC

busca la programaci on en 3 capas:

Modelo: tienes los datos y su implementaci on dene como se leen y escriben 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 m as abstractas son las m as reutilizables. Vista: o presentaci on, 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 ogica de negocio, implementa la l ogica de lo que le pasa a los modelos en funci on de los eventos que vienen de la Vista. Algunos ejemplos de implementaci on de MVC son Rails(Ruby), Structs(Java), CakePHP,Kumbia,Symfony(PHP), TurboGears,Django(Python) ... etc. Los frameworks m as impactantes son Ruby on Rails y Django, estan orientados al desarrollo web eciente. Su objetivo es dar la opci on de base de datos. Creamos las clase modelo y sus tables son creadas automaticamente, y actualizadas cuando modiquemos el modelo.

1.3.

Sistema Web

El servidor web ofrece p aginas web y otos recursos (css, js, imagenes, ash ...) Estos recursos se identican de forma u nica mediante URL o URI. Los servidores web utilizan la comunicaci on entre cliente y servidor utiliza el protocolo HTTP. No mantiene conexi on tras una petici on. Eso genera, que sea necesario recurrir a cookies para conocer el estado del cliente. (Sesiones) Una aplicaci on web genera una p agina web para un cliente en funci on de N variables. (diferenciar p agina de aplicaci on) Una aplicaci on web es un sistema Web que nos ofrece la l ogica de negocio. (interfaces, formularios ...). Hace de frontend. Lenguajes en la parte del cliente Lenguajes de script como javascript (est andar ECMA), y Visual Basic Script(Microsoft). Pueden usarse para complementar la l ogica de negocio. Alivian al servidor. La web es sincrona pero la tendencia es la Web as ncrona gracias a un conjunto de t ecnolog as denominadas como AJAX. Para el renderizado Web se usa HTML, XHTML o XML. Complementados con CSS (hojas de estilo en cascada) Flash como lenguaje de presentaci on. Aporta multimedia a la web. Applet java ... Lenguajes en la parte del servidor Los m as 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 on del software, no solo se usa en programaci on Web

llegar a tener mezcladas las tres capas: presentaci on(XHTML), l ogica de negocio(PHP) y modelo de datos(SQL). Procedimentales. La separaci on de capas es dicil ya que tradicionalmente la l ogica de negocio se encarga de generar la presentaci on dinamicamente. En aplicaciones grandes, es preferible por usar lenguajes que implementan MVC

2.

Evoluci on de las metodolog as Web

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

2.1.

Entidad-Relaci on

Aunque es un buen diagrama y podr a ser necesario para toda aplicaci on 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 u nico lenguaje de modelado que nos permitiera modelar todo y de forma m as integrada. Esto es as porque sencillamente ER no fue dise nado 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 no de una aplicaci on de hipertexto. Es un intento de modelar la estructura del hipertexto-hipermedia, una modelizaci on de las estructuras de navegaci on. Crear un modelo antes de desarrollar un hipertexto nos ayudar aa conseguir una navegaci on m as consistente y rica. En HDM la estructura de navegaci on viene marcada por la estructura de datos. Fue en principio usado para p aginas est aticas.

2.3.

RMM

Basado en E/R. Esta metodolog a es apropiada para clases de objetos bien denidas, y con claras relaciones entre esas clases Est a orientada a problemas con datos din amicos que cambian con mucha frecuencia, m as que a entornos est aticos como HDM Sin embargo, los mecanismos de acceso a la informaci on son excesivamente simples y valen para un problema con pocas entidades, pero el modelo se queda corto si hay gran n umero de ellas.

2.4.

WebML

En principio no coge nada de UML, aunque actualmente existen diagramas que los relacionan. Es una notaci on visual para el dise no de aplicaciones Web complejas que hacen uniso de datos intenso. Provee especicaciones gr acas formales para un proceso de dise no completo que puede ser asistido por herramientas de dise no visuales. Tiene UNA herramienta comercial CASE orientada a jsp (WebRatio). Realmente es un plugin de Eclipse. Estructura WebML Sitio = Estructura + Composici on + Navegaci on + Presentaci on

3.

WAE y WAE2

Es el u 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 as barato hacer un estandar ampliando que cre andolo de cero. Lo primero que se plantea es que las aplicaciones Web presentan problemas que UML no contempla soluci on. UML no facilita la tarea de diferenciar c odigo cliente (scripts) de c odigo servidor. UML puede ser extendido para permitir una nueva sem antica : estereotipos, listados de etiquetas(tags) y restricciones(constraints): Estereotipos: dene una nueva sem antica al modelo. 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 p aginas que contienen scripts o c odigo ejecutable por el servidor. (.php , .asp , .jsp) <<Client Page>> Son las p aginas que estan en el lado del cliente, normalmente p aginas HTML y scripts (jsvascript). <<Form>> Es la representaci on de un formulario. Es c odigo HTML que 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 relaci on entre una p agina servidor y una p agina cliente. La p agina servidor construye a la p agina cliente. <<link>> Es una relaci on entre una p agina y otra p agina del sistema. <<submit>> Es una relaci on entre un formulario y un servidor de p agina

3.2.

Diagramas de Componentes

Ilustran las piezas del software que conformar an un sistema. Un componente pueden ser un ejecutable, una librer a est atica o din amica, 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 agina de servidor genera una p agina de cliente, 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 funci on 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 on del tiempo. Su uso respecto a UML no 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 funci on.

4.

Propuesta de metodolog a agil

Se propone una metodolog a agil basada en una propuesto de Ricardo Galli (un referente en el software libre, creador de meneame y bulma entre otros proyectos). Modicar esta metodolog a para integrar UML en las fases de dise no. Tiene al menos 4 fases: 1. Dise no conceptual 2. Dise no gr aco, arbol de navegaci on y base de datos 3. Desarrollo a ) Desarrollo gr aco y HTML b ) Desarrollo de l ogica de negocio y bases de datos c ) Pruebas y benchmark 4. Producci on

4.1.

Dise no conceptual

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 dise no y funcionalidad muy b asica. Es la llamada Proof of concept nos ayuda a convencer al cliente y a tener un primer an alisis y dise no previo.

4.2.

Dise no gr aco, arb. de navegaci on y base de datos

Tras la abstracci on de requisitos que desea el cliente los dise nadores gr acos deben ir comenzando con los bocetos basados en la prueba de concepto, los dise nadores gr acos deben comunicarse con los programadores, si bien un dise nador no deben conocer la l ogica si deben conocer las restricciones que le imponen el dise no. Mientras tanto los programadores pueden ir planteando los dise nos de aplicaci on y base de datos.

4.3.

Desarrollo

Es recomendable realizar el desarrollo en varias fases: 4.3.1. Desarrollo gr aco y HTML

No podemos exigir a un dise nador conocimientos de programaci on. Cada dise nador puede usar sus herramientas favoritas, siempre que cumpla el estandar y codicaci on especicados por el proyecto. Por ejemplo, exigir que use un editor con las siguientes caracter sticas: XHTML 1.0 Strict + UTF8. Los dise nadores crear an los gr acos, y el c odigo HTML, en el contenido din amico (contenido que vendra del modelo de datos) escribier an ejemplos. Los programadores pueden hacer recomendaciones a los dise nadores para evitar problemas de integraci on. Deben comentar las secciones del HTML, documentar cada XPATH del CSS Validar la p agina por W3C durante el desarrollo gr aco (HTML , CSS , AAA ...). Alg un consejo que se le suela dar a los dise nadores : Es mejor no usar las caracter sticas m as novedosas de los navegadores(aunque es discutible). Tener un criterio al nombrar las p aginas acorde al modelo de datos. Usar siempre rutas relativas para facilitir la migraci on del proyecto. Los dise nadores deben preocuparse de la accesibilidad : UIML (User Interface Markup Language) es un lenguaje de extensi on del XML que promueve la creaci on de p aginas web que puedan ser vistas en cualquier dispositivo como monitores para PC, tel efonos 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 ogica de negocio y base de datos

Al tiempo, los programadores van implementando la l ogica y el modelo de datos, har an sus pruebas con HTML muy simple. El proyecto deber a estar en un repositorio, con acceso remoto (SSH) en cualquier momento del d a, esto dar a exibilidad de horario. Los dise nadores deber an terminar antes, estos modulos nalizados se i ran 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.

5.

Conclusiones
Se concluye que UML se puede ampliar al modelo web con componentes espec cos como las p aginas, enlaces, cliente de scripts y otras formas abstracci on 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 aplicaciones 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 as impacto tienen hoy en d a son Rails y Django. (Basados en MVC) Opini on personal : actualmente los sistemas web no se les exige tanta calidad como en el software tradicional, esto unido a los grupos de desarrollo tan peque nos, 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 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