• Author / Uploaded
• Cadm Cadmo

• Categories
• Servidor web
• Lenguaje de modelado unificado
• HTML
• Script Java
• Red mundial

Citation preview

Aplicaciones Web con UML Ricardo Marmolejo Garc´ıa Ingenier´ıa del software

´Indice 1. Introducci´ on

2

1.1. ¿Qu´e es UML? . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2. Patr´ on Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . .

3

1.3. Sistema Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2. Evoluci´ on de las metodolog´ıas Web

4

2.1. Entidad-Relaci´ on . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 metodolog´ıa ´ agil

7

4.1. Dise˜ no conceptual . . . . . . . . . . . . . . . . . . . . . . . . . .

7

4.2. Dise˜ no gr´ afico, arb. de navegaci´on y base de datos . . . . . . . .

7

4.3. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

4.3.1. Desarrollo gr´afico y HTML . . . . . . . . . . . . . . . . .

8

4.3.2. Desarrollo de l´ogica de negocio y base de datos . . . . . .

8

4.3.3. Pruebas y benchmark . . . . . . . . . . . . . . . . . . . .

8

5. Conclusiones

9

6. Bibliograf´ıa

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 simplifican 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´afico 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 insuficiente sem´anticamente para Aplicaciones Web (en principio). 1 Referente

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

2

1.2.

Patr´ on Modelo-Vista-Controlador

El patr´ on MVC

4

busca la programaci´on en 3 capas:

Modelo: tienes los datos y su implementaci´on 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. Las clases que se definen 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 eficiente. Su objetivo es dar la opci´on 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 p´ aginas web y otos recursos (css, js, imagenes, flash ...) Estos recursos se identifican 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

3

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 dificil 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´a a 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 definidas, 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.

4

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 especificaciones gr´aficas 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: define una nueva sem´antica 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.

3.1.

Tipos de estereotipos

3.1.1.

En las entidades

Esto son los principales estereotipos que se definen: Son las p´aginas que contienen scripts o c´odigo ejecutable por el servidor. (.php , .asp , .jsp) Son las p´aginas que estan en el lado del cliente, normalmente p´ aginas HTML y scripts (jsvascript). Es la representaci´on de un formulario. Es c´odigo HTML que contiene etiquetas de formulario como : , , ... 5

Estos estereotipos se pueden ampliar con mucha flexibilidad. Otros ejemplos de estereotipo pueden ser : , o . 3.1.2.

En las relaciones

Define los siguientes estereotipos para las relaciones: Una relaci´on entre una p´agina servidor y una p´agina cliente. La p´ agina servidor ”construye” a la p´agina cliente. Es una relaci´on entre una p´agina y otra p´agina del sistema. 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, flash ...

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 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 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). Modificar 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´ afico, arbol de navegaci´on y base de datos 3. Desarrollo a) Desarrollo gr´ afico 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 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˜ 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´ afico, arb. de navegaci´ on y base de datos

Tras la abstracci´ on de requisitos que desea el cliente los dise˜ nadores gr´aficos deben ir comenzando con los bocetos basados en la prueba de concepto, los dise˜ nadores gr´ aficos 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.

7

4.3.

Desarrollo

Es recomendable realizar el desarrollo en varias fases: 4.3.1.

Desarrollo gr´ afico 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 codificaci´ on especificados 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´ aficos, 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´afico (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 flexibilidad de horario. Los dise˜ nadores deber´ıan terminar antes, estos modulos finalizados 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.

8

5.

Conclusiones Se concluye que UML se puede ampliar al modelo web con componentes espec´ıficos 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.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

9