Aplicaciones Web con UML

1. Aplicaciones Web con UML Ingienería del software • Ricardo Marmolejo García

2. Objetivos • Introducción • Conceptos : UML , MVC, Sistemas Web • Lenguajes en el cliente y en el servidor • Algunas Metodologías Web • WAE y WAE2 • Metodología Ágil • Conclusiones

3. Introducción I • Los sistemas web son relativamente nuevos en el mundo del computación. Son un nuevo reto para los ingenieros del software. • Las aplicaciones web son cada vez más complejas. • Como el software, al principio no se modelaba, pronto surgen metodologías que intentan solucionar el problema. • Los sistemas Web fomentan un entorno de requisitos muy cambiantes. • Gran numero de usuarios y/o requisitos (mundial) • El equipo de desarrolladores suele ser pequeño

4. Introducción II • Los modelos son abstracciones que simplifican nuestra comprensión de los sistemas. • Como lenguaje de modelado ya existente deberiamos considerar si UML tiene capacidad para modelar en aplicaciones Web • Jim Conallen recomienda modelar webs extediendo UML y aplicacando un patrón de diseño llamado MVC (modelo-vista-controlador). • Conceptos a ver: UML , MVC, sistema Web y Lenguajes en el cliente y en el servidor.

5. 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. • Creadores : Grady Booch, Ivar Jacobson y James Rumbaugh • Dependiendo del concepto que queremos comunicar, usaremos un diagrama u otro. • UML es insuficiente semánticamente para Aplicaciones Web (en principio).

6. 2 . Patrón Modelo-Vista-Controlador I • Esta patrón (de software) busca la programación por capas: • Modelo: tienes los datos y su implementación define 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. Altamente reutilizable. • Vista: 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.

7. 2 . Patrón Modelo-Vista-Controlador II • Algunos ejemplos de implementación de MVC son Rails(Ruby), Structs(Java), CakePHP,Kumbia,Symfony(PHP), TurboGears,Django(Python) ... etc • Ruby on Rails y Django son frameworks orientados al desarrollo web eficiente. Estos abstraen el uso de base de datos.

8. 3 . Sistema Web 1/2 • El servidor web ofrece páginas web y recursos (css, js, imagenes, flash ...) • Los recursos se identifican de forma única mediante URL o URI.

9. 3 . Sistema Web 2/2 • 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.

10. Lenguajes en la parte del cliente • Lenguajes de script como javascript (estándar ECMA), y Visual Basic 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 renderizado 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 ...

11. 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 llegar a tener mezcladas las tres capas: presentación(XHTML), lógica de negocio(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

12. Complejidad sistemas web

13. Histórico

14. Entidad-Relación • No fue diseñado para uso de modelado de aplicaciones Web

15. HDM • Basado de 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. • En principio usado para páginas estáticas

16. 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.

17. WebML • En principio no coge nada de UML, aunque actualmente existen diagramas para relacionarlos. • Es una notación visual para el diseño de aplicaciones Web complejas que usan datos intensivamente. • 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.

18. Estructura WebML • Sitio = Estructura + Composición + + Navegación + Presentación

19. WAE y WAE2 • Es el único exclusivamente basado en UML. • Desarrollado por Jim Conallen (Rational Software Corporation) • WAE como UML es recomendado usarlo en lenguajes orientdados a objetos. • Es más barato hacer un estandar ampliando que creándolo de cero. • Las aplicaciones Web presentan problemas que UML no contempla solución. • Dificultad para diferenciar código cliente (scripts) de código servidor.

20. WAE y WAE2 • Jim Conallen desarrolla WAE y WAE2 basandose en estereotipos, listados de etiquetas(tags) y restricciones(constraints) que proporciona UML • UML puede ser extendido para permitir nueva semántica: • 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 estereotipos.

21. Estereotipos en clases • Define los siguientes estereotipos para las entidades. • Tipos de estereotipo en clases principales: • <<Server Page>> Son las páginas que contienen scripts o código ejecutable 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> ...

22. Estereotipos en relaciones • Define los siguientes estereotipos para las relaciones. • Tipos de estereotipo en 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

23. Añadidos al <<Client Page>> • Añadidos • Script • Formulario • Flash • Applet

24. Iconos de los estereotipos

25. Diagrama de Componentes • Los Diagramas de Componentes ilustran las piezas del software que conformarán un sistema. Pueden ser: ejecutables, librerías estáticas o dinámicas, clases de Java, ... Tienen Interfaz • Los estereotipos de las componentes pueden ser <<Pagina PHP>> o <<Pagina HTML>> por ejemplo. • Encapsula <<Cliente Page>> y <<Server Page>> en un componente <<Pagina PHP>> • Las páginas estaticas sólo implementara la parte del cliente • Las dinámicas implemente cliente y servidor

26. Casos de uso • Los casos de uso de una aplicación web son igual de útiles que en una aplicación de software. Su funcionamiento es igual. • Con especial incapie debemos tener en cuenta que tenemos visitantes de diferentes 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.

27. Diagrama de secuencia • Explica un caso de uso en función del tiempo. • Se usa como en UML. • Aparecen las lineas de tiempo de los actores y componentes implicadas. • Actores y componentes se envian mensajes entre ellos. • Las paginas del cliente pueden enviarse mensajes a si mismo (funciones javascript donde el servidor no interviene) • La tecnología web es sincrona. Las flechas asincronas solo pueden ser interpretadas como el uso de AJAX.

28. Eventos en el cliente • Los eventos de cliente = eventos de javascript como onClick , onLoad, etc ... • Pueden ser introducidos en el modelo como listas de etiquetas donde el campo es el nombre del evento y el valor es el nombre de la función. • En la clase pondremos las variables y los metodos, que normalmente vienen de javascript.

29. Metodología ágil • Metodología ágil (No usa UML necesariamente) • Tiene al menos 4 fases: • Diseño conceptual • Diseño gráfico y arbol de navegación • Desarrollo • Desarrollo gráfico y HTML • Desarrollo de lógica de negocio y bases de datos • Pruebas y benchmark • Producción

30. Diseño conceptual • 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 funcionalidad muy básica. • ”Proof of concept” → Ayuda a convencer al cliente y a tener un primer análisis y diseño previo.

31. Diseño gráfico y arb. de navegación • Aqui 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. • Los programadores pueden ir planteando los diseños de aplicación y base de datos.

32. Desarrollo gráfico y HTML 1/3 • 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 codificación especificados por el proyecto. Por ejemplo: XHTML 1.0 Strict + UTF8 • Los diseñadores crearán los gráficos, y el código HTML, en el contenido dinámico escribierán ejemplos.

33. Desarrollo gráfico y HTML 2/3 • Los programadores pueden hacer recomendaciones a los diseñadores para evitar problemas de integración. • 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 : • Es mejor no usar las características más novedosas de los navegadores. • Tener un criterio al nombrar las páginas acorde al modelo de datos. • Rutas relativas.

34. Desarrollo gráfico y HTML 3/3 • UIML (User Interface Markup Language) Lenguaje de extensión del XML que promueve la creación de páginas web que puedan ser vistas en cualquier dispositivo como 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 ...)

35. Desarrollo de lógica de negocio • Al tiempo, los programadores van programando, haciendo pruebas con HTML muy simple. • El proyecto debería estar en un repositorio, con acceso remoto (SSH) en cualquier momento del día. Flexibilidad de horario. Productividad. • Los modulos finalizados por los diseñadores se iŕan integrando paulatinamente. • Pruebas, si tenemos un producto funcional se puede ir mostrando al cliente y pedirle que haga pruebas y revise requisitos.

36. Conclusiones sobre UML y la WEB • 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 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ás impacto tienen hoy en día son Rails y Django. (Basados en MVC)

37. 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