Transcript blogricardo.files.wordpress.com

Aplicaciones Web con UML
Ingienería del software
Ricardo Marmolejo García
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
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
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.
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).
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.
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.
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.
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.
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 ...
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
Complejidad sistemas web
Histórico
Entidad-Relación

No fue diseñado para uso de modelado de
aplicaciones Web
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
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.
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.
Estructura WebML

Sitio = Estructura + Composición +
+ Navegación + Presentación
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.
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.
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> ...
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
Añadidos al <<Client Page>>

Añadidos

Script

Formulario

Flash

Applet
Iconos de los estereotipos
<<server page>>
<<client page>>
<<build>>
shopcart
mycart
<<server page>>
updatecart
<<link>>
<<submit>>
<<form>>
cartform
dailyspecial
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>>
<<build>>
shopcart
mycart
Las páginas estaticas sólo
implementara la parte del cliente
Las dinámicas implemente cliente y
servidor
<<ASP Page>>
shopcart.asp
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.
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.
Eventos en el cliente
<<Client Page>>
OnLineCart
{ onLoad=bodyOnLoad() }
itemCount : integer
subTotal : currency
tax : currency
total : currency
taxRate : currency

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
recalculateTotals()
updateForm()
valor es el nombre de la
bodyOnLoad()
función.
 En la clase pondremos las variables y los metodos,
que normalmente vienen de javascript.

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
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.
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.
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.
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.
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 ...)
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.
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)
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-yframeworks/

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