BENEMRITA UNIVERSIDAD AUTNOMA DE PUEBLA

FACULTAD DE CIENCIAS DE LA COMPUTACIN

DESARROLLO DE APLICACIONES WEB USANDO UML

TESIS PROFESIONAL
QUE PARA OBTENER EL TTULO DE

LICENCIADO EN CIENCIAS DE LA COMPUTACIN

PRESENTA

ALBERTO LPEZ AGUILAR

ASESOR

DR. ABRAHAM SNCHEZ LPEZ

PUEBLA, PUE. 2005

AGRADECIMIENTOS
Expreso todo mi agradecimiento a mis padres que son parte importante en mi vida e inspiracin para seguir adelante, con todo mi cario y amor les dedico ste trabajo de tesis y tambin a mi hermana Elizabeth Lpez Aguilar que es parte fundamental en la culminacin de esta etapa importante para mi. De igual forma agradezco al Dr. Abraham Snchez Lpez, que sin duda sus palabras de aliento fueron de gran importancia para terminar de una buena manera ste trabajo de tesis. Tambin est dedicado a mis profesores de la licenciatura que intervinieron en mi formacin acadmica. Y sin duda a mis amigos, amigas y personas que estuvieron en momento de gran importancia para la culminacin de lo que alguna vez fue un sueo y que se volvi realidad. A todos:

GRACIAS!

INDICE
Prefacio 1. Introduccin a la Web 1.1 Historia de la Web 1.2 Historia de las aplicaciones Web 1.3 Qu es una aplicacin Web? 1.4 Por qu usar metodologas en el desarrollo de aplicaciones Web? 2. UML 2.1 Introduccin a UML 2.2 reas de trabajo en UML 2.3 Proceso Unificado (Unified Process, UP) 2.4 Descripcin de los diagramas de UML 3. Metodologas de desarrollo de aplicaciones Web 3.1 Introduccin al desarrollo de aplicaciones Web 3.2 UWE (Ingeniera Web basada en UML) 3.3 WAE (Extensin de Aplicaciones Web para UML) 3.4 Metodologas Basadas en Hipermedia y Orientadas a Objetos 3.4.1 Qu es Multimedia? 3.4.2 Qu es la Hipermedia? 3.4.3 SOHDM (Metodologa de Diseo Hipermedia Orientado a Objetos y basada en escenarios) 3.4.4 OOHDM (Mtodo de Diseo Hipermedia Orientado a Objetos) 3.4.5 W2000 3.4.6 EORM (Metodologa de Relaciones de Objetos Mejorada) 3.5 Conclusin 4. Metodologa WAE para el desarrollo de las aplicaciones Web para UML 4.1 WAE (Extensin de Aplicaciones Web para UML) 4.2 Modelado 4.2.1 Pginas 4.2.2 Servidor Scripting 4.2.3 Cliente Scripting 4.2.4 Estereotipos de Pginas 4.3 Componentes 4.3.1 Forms (Formularios) 4.3.2 Framesets 5. Prototipo de una Tienda Virtual 5.1 Descripcin de la aplicacin Web (Tienda Virtual) a modelar en UML 5.2 Modelando la parte del usuario de la Tienda Virtual 5.3 Modelando la parte del administrador de la Tienda Virtual 6. Conclusiones y perspectivas 7. Bibliografa 1 4 5 6 8 9 9 10 17 18 19 19 20 21 22 23 23 24 25 29 29 29 30 30 33 33 34 36 36 40 48 50

II

PREFACIO
El objetivo de esta tesis es investigar la manera en que UML puede ser aplicado al desarrollo de aplicaciones Web, y aportar una metodologa para el desarrollo de estas aplicaciones. El lenguaje de modelado unificado (UML) es un estndar industrial para describir diseos. UML no es una metodologa, sino un lenguaje. Se basa en las anteriores especificaciones de BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un nmero de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representan la arquitectura del proyecto. Con UML nos debemos olvidar del protagonismo excesivo que se le da al diagrama de clases, este representa una parte importante del sistema, pero solo representa una vista esttica, es decir, muestra al sistema parado. Sabemos su estructura pero no sabemos que sucede a sus diferentes partes cuando el sistema empieza a funcionar. UML introduce nuevos diagramas que representan una visin dinmica del sistema. Es decir, gracias al diseo de la parte dinmica del sistema podemos darnos cuenta en la fase de diseo de problemas de la estructura al propagar errores o de las partes que necesitan ser sincronizadas, as como del estado de cada una de las instancias en cada momento. El diagrama de clases continua siendo muy importante, pero se debe tener en cuenta que su representacin es limitada, y que ayuda a disear un sistema robusto con partes reutilizables, pero no a solucionar problemas de propagacin de mensajes ni de sincronizacin o recuperacin ante estados de errores. En resumen, un sistema debe estar bien diseado, pero tambin debe funcionar bien. UML tambin intenta solucionar el problema de propiedad de cdigo que se da con los desarrolladores, al implementar un lenguaje de modelado comn para todo los desarrollos se crea una documentacin tambin comn, que cualquier desarrollador con conocimientos de UML ser capaz de entender, independientemente del lenguaje utilizado para el desarrollo. UML es ahora un estndar, no existe otra especificacin de diseo orientado a objetos, ya que es el resultado de las tres opciones existentes en el mercado. Su utilizacin es independiente del lenguaje de programacin y de las caractersticas de los proyectos, ya que UML ha sido diseado para modelar cualquier tipo de proyectos, tanto informticos como de arquitectura, o de cualquier otra rea. UML permite la modificacin de todos sus miembros mediante estereotipos y restricciones. Un estereotipo nos permite indicar especificaciones del lenguaje al que se refiere el diagrama de UML. Una restriccin identifica un comportamiento forzado de una clase o relacin, es decir, mediante la restriccin estamos forzando el comportamiento que debe tener el objeto al que se le aplica. A continuacin se realiza un pequeo resumen por captulo de esta tesina: En el Captulo 1 se presenta la historia de Internet y cuales eran el tipo de tecnologas que se utilizaban para el desarrollo de las aplicaciones Web; adems la definicin de lo que es una aplicacin Web y la arquitectura de ste tipo de aplicaciones. Se presenta porque es necesaria la utilizacin de una metodologa para las aplicaciones Web.

III En el Captulo 2 presenta el surgimiento de UML, su evolucin, reas de trabajo y un marco para la definicin de software basado en esta notacin. Adems de la descripcin de los diagramas que conforman a UML. En el Captulo 3 se abordan las metodologas que pueden ser utilizadas para el desarrollo de aplicaciones Web. En el Captulo 4 se describe la metodologa WAE de una manera extensa y porque sta metodologa es la ms completa para la realizacin de aplicaciones Web. En el Captulo 5 se presenta el prototipo realizado con la metodologa WAE. Finalmente en el Captulo 6 se presentan las conclusiones de este trabajo.

1. INTRODUCCIN A LA WEB
1.1 Historia de la Web Internet [18], la red de redes, nace a mediados de la dcada de los setentas, bajo los auspicios de DARPA, la Agencia de Proyectos Avanzados para la Defensa de Estados Unidos. DARPA inicio un programa de investigacin de tcnicas y tecnologas para unir diversas redes de conmutacin de paquetes, permitiendo as a las computadoras conectadas a estas redes comunicarse entre s de forma fcil y transparente. De estos proyectos naci un protocolo de comunicacin de datos, IP o Internet Protocol, que permita a computadoras diversas comunicarse a travs de una red, Internet, formada por la interconexin de diversas redes. A mediados de los ochentas la Fundacin Nacional para la ciencia norteamericana, la NSF, cre una red, la NSFNET, que se convirti en el backbone (el troncal) de Internet junto con otras redes similares creadas por la NASA (NSINet) y U.S. DoE (Department of Energy) con la ESNET. En Europa, la mayora de pases disponan de backbones nacionales (NORDUNET, RedIRIS, SWITCH, etc.) y de una serie de actividades paneuropeas (EARN y RARE). En esta poca aparecen los primeros proveedores de acceso a Internet privados que ofrecen acceso pagado a Internet. A partir de esta poca, gracias entre otras cosas a la amplia disponibilidad de implementaciones de las suite de protocolos TCP/IP (formada por todos los protocolos de Internet y no slo por TCP e IP), algunas de las cuales eran ya de cdigo libre, Internet empez lo que a mediados del 2002 empieza a descender ligeramente el ritmo de crecimiento. A mediados de los noventas se inici el boom de Internet. En esa poca el nmero de proveedores de acceso privado se dispar, permitiendo a millones de personas acceder a Internet, que a partir de ese momento ya se empez a conocer como la Red, desbancando a las dems redes de comunicacin existentes (Compuserver, FidoNet/BBS, etc.). El punto de inflexin vino marcado por la aparicin de implementaciones de TCP/IP gratuitas as como por la popularidad y abaratamiento de los medios de acceso cada vez ms rpidos. El efecto de todos estos cambios fue como una bola de nieve: a medida que se conectaban ms usuarios, los costos se reducan, aparecan ms proveedores e Internet se haca ms atractiva y econmica, con lo que se conectaban ms usuarios. En estos momentos disponer de una direccin de correo electrnico, de acceso a la Web, etc., ha dejado de ser una novedad para convertirse en algo normal en muchos pases del mundo. Por eso las empresas, instituciones, administraciones y dems estn migrando rpidamente todos sus servicios, aplicaciones, tiendas, etc., a un entorno Web que permita a sus clientes y usuarios acceder a todo ello por Internet. A pesar del ligero descanso experimentado en el ritmo de crecimiento, Internet est destinado a convertirse en una suerte de servicios universal de comunicaciones, permitiendo una comunicacin universal. La WWW (World Wide Web) [18], se ha convertido, junto con el correo electrnico en el principal caballo de batalla de Internet. sta ha dejado de ser una inmensa biblioteca de pginas estticas para convertirse en un servicio que permite acceder a

2 multitud de prestaciones y funciones, as como a infinidad de servicios, programas, tiendas, etc. En 1989, mientras trabajaba en el CERN (Centro Europeo de Investigacin Nuclear), Tim Berners-Lee empez a disear un sistema para hacer accesible fcilmente la informacin del CERN. Dicho sistemas empleaba el hipertexto para estructurar una red de enlaces entre los documentos. Una vez obtenida la aprobacin para continuar el proyecto, naci el primer navegador Web, llamado WorldWideWeb. En 1992 el sistema ya se haba extendido fuera del CERN. El nmero de servidores estables haba aumentado, alcanzando la sorprendente cifra de veintisis. A partir de este punto, el crecimiento es espectacular. En 1993 fue el lanzamiento de Mosaic, un navegador para X-Windows que con el tiempo se convertira en Netscape y que fue un factor clave de popularidad de la Web. En 1994 se fund la WWW Consortium, que se convertira en el motor de desarrollo de los estndares predominantes en la Web. A partir de ese momento, el crecimiento ya fue constante, convirtindose hacia finales de los noventas en el servicio insignia de Internet y dando lugar al crecimiento imparable de los servicios en lnea que estamos experimentando actualmente. El xito espectacular de la Web se basa en dos puntales fundamentos: el protocolo HTTP y el lenguaje HTML. Uno permite una implantacin simple y sencilla de un sistema de comunicaciones que nos permite enviar cualquier tipo de ficheros de una forma fcil, simplificando el funcionamiento del servidor y permitiendo que servidores poco potentes atiendan miles de peticiones y reduzcan los costos de despliegue. El otro nos proporciona un mecanismo de composicin de pginas enlazadas simple y fcil, altamente eficiente y de uso muy simple. El protocolo HTTP (Hypertext Transfer Protocol) [11, 18] es el protocolo base de la WWW. Se trata de un protocolo simple, orientado a conexin y sin estado. La razn de que est orientado a conexin es que emplea para su funcionamiento un protocolo de comunicaciones (TCP, transport control protocol) de modo conectado, un protocolo que establece un canal de comunicaciones de extremo a extremo (entre el cliente y el servido) por el que pasa el flujo de bytes que constituyen los datos que hay que transferir, en contraposicin a los protocolos de datagrama o no orientados a conexin que dividen los datos en pequeos paquetes (datagramas) y los envan, pudiendo llegar por vas diferentes del servidor al cliente. El protocolo no mantiene estado, es decir, cada transferencia de datos es una conexin independiente de la anterior sin relacin alguna entre ellas, hasta el punto de que para transferir un pgina Web tenemos que enviar cdigo HTML del texto, as como las imgenes que la componen, pues en la especificacin inicial de HTTP, la 1.0, se abran y usaban tantas conexiones como componentes tena la pgina, transfirindose por cada conexin un componente (el texto de la pgina o cada una de las imgenes). Existe una variante de HTTP llamada HTTPS (S por secure) que utiliza el protocolo de seguridad SSL (secure socket layer) para cifrar y autenticar el trfico entre cliente y servidor, siendo sta muy usada por los servidores Web de comercio electrnico, as como por aquellos que contienen informacin personal o confidencial.

3 De manera esquemtica, el funcionamiento de HTTP [11,18] es el siguiente: el cliente establece una conexin TCP hacia el servidor, hacia el puerto HTTP (o el indicado en la direccin de la conexin), enva un comando HTTP de peticin de un recurso y por la misma conexin el servidor responde con los datos solicitados y con algunas cabeceras informativas (Ver figura 1.1).

Figura 1.1 Arquitectura Cliente/Servidor El trmino Cliente/Servidor alude a un procesamiento colaborativo de datos entre dos o ms computadoras conectadas en una red. Los principales componentes de la arquitectura Cliente/Servidor son: clientes, servidores y la infraestructura de comunicacin. Se denomina cliente al proceso que indica el dilogo o solicita los recursos y se denomina servidor al proceso que responde a las solicitudes hechas por parte del cliente. Las aplicaciones en el cliente y en el servidor se dividen de la siguiente manera: el servidor contiene la parte que debe ser compartida por varios usuarios y el cliente contiene solamente lo particular de cada usuario. Los clientes interactan con el usuario usualmente en forma grfica, frecuentemente se comunican con proceso auxiliares que se encargan de establecer conexin con el servidor, enviar el pedido, recibir la respuesta, maneja las fallas y realiza actividades de sincronizacin y de seguridad. Los servidores proporcionan un servicio al cliente y devuelven los resultados, en algunos casos existen procesos auxiliares que se encargan de recibir las solicitudes del cliente, verificar la proteccin, activar un proceso servidor para satisfacer el pedido, recibir su respuesta y enviarla al cliente. Una de las ms significantes ventajas de una aplicacin Web es el despliegue. Otro punto importante del xito de la WWW ha sido el lenguaje HTML (Hypertext Mark-up Language). Se trata de un lenguaje de marcas que nos permite representar de forma rica el contenido y tambin referenciar otros recurso, enlaces a tros documentos

4 (la caracterstica ms destacada de la WWW), mostrar formularios para posteriormente procesarlos, etc. El lenguaje HTML actualmente se encuentra en la versin 4.01 y empieza a proporcionar funcionalidades ms avanzadas para crear pginas ms ricas en contenido. Adems se ha definido una especificacin compatible con HTML, el XHTML (eXtensible Hypertext Markup Language) que suele definir como una versin XML validable de HTML, proporcionndonos un XML Schema contra el que validar el documento para comprobar si est bien formado, etc. 1.2 Historia de las aplicaciones Web Inicialmente la Web era simplemente una coleccin de pginas estticas, documentos, etc., que podan consultarse o descargarse. El siguiente paso en su evolucin fue la inclusin de un mtodo para confeccionar pginas dinmicas que permitiesen que lo mostrado fuese dinmico (generado o calculado a partir de los datos de la peticin). Dichos mtodos fueron conocidos como: CGI (Common Gateway Interface). [18] Y defina un mecanismo mediante el cual podamos pasar informacin entre el servidor HTTP y programas externos. Los CGI siguen siendo muy utilizados, puesto que la mayora de los servidores Web los soportan debido a su sencillez. Adems, nos proporcionan total libertad a la hora de escoger el lenguaje de programacin para desarrollarlos. El esquema de funcionamiento de los CGI tena un punto dbil: cada vez que recibamos una peticin, el servidor Web lanzaba un proceso que ejecutaba el programa CGI. Como, por otro lado, la mayora de los CGI estaba escrito en algn lenguaje interpretado (Perl, Python, etc.) o en algn lenguaje que requera run-time environment (Visual Basic, Java, etc.), esto implicaba una gran carga para la mquina del servidor. Adems, si la Web tena muchos accesos al CGI, esto supona problemas graves. Por ello se empiezan a desarrollar alternativas a los CGI para solucionar este grave problema de rendimiento. Las soluciones vienen principalmente por dos vas. Por un lado se disean sistemas de ejecucin de mdulos ms integrados con el servidor, que evitan que ste tenga que instanciar y ejecutar multitud de programas. La otra va consiste en dotar al servidor de un intrprete de algn lenguaje de programacin (RXML, PHP, VBScript, etc.) que nos permita incluir las pginas en el cdigo de manera que el servidor sea quien lo ejecute, reduciendo as el tiempo de respuesta. Fast- CGI. Esta es una solucin similar al CGI mencionado anteriormente, solo que propone la creacin de un solo proceso persistente por cada programa FastCGI en lugar de por cada solicitud del cliente. Es una solucin viable pero tambin tiene inconvenientes de proliferacin de procesos en el caso de peticiones concurrentes. Pginas dinmicas en servidor. Con la aparicin de esta tecnologa se entra a una nueva forma de trabajo, la cual esta orientada al trabajo del diseador Web, quien no necesariamente conocer de lenguajes de programacin. Este nuevo enfoque consiste en insertar pequeos fragmentos de lgica de programacin en la estructura HTML de la pgina, al contrario de lo que se hacia en los CGIs, que era en el lenguaje de programacin que utiliza sentencias de impresin para generar salidas HTML. En este

5 sentido se conocen diferentes alternativas, entre ellas podemos mencionar PHP, ASP, JSP, entre otros. Servlets. El Servlet podemos considerarlo como una evolucin de los CGIs desarrollada por SUN Microsystems como parte de la tecnologa JAVA. De forma general consiste en la ejecucin de aplicaciones Java en el motor de servlets (Servlet engine) el cual hace parte del servidor Web, algo que lo hace ventajoso con respecto a los CGIs es que por cada peticin de usuario no se crea un proceso sino un hilo, el cual es mucho mas econmico para el sistema. Esta tecnologa hace parte de la arquitectura propuesta por SUN en su plataforma J2EE (Java 2 Enterprise Edition). Servicios Web. La arquitectura de servicios Web plantea algo ms que una tcnica para el desarrollo de aplicaciones Web, representa un modelo de computacin distribuida para Internet basado en XML (eXtensible Markup Language). Bajo este concepto ya no solo se trata la comunicacin usuario-aplicacin, sino que de manera adicional se maneja la interaccin aplicacin-aplicacin. Para aclarar un poco ms el concepto tomemos como ejemplo una rutina de programacin, como sabemos una rutina es como una caja negra, la cual encierra un proceso y que cumple una funcin claramente definida, luego para construir una aplicacin llamamos dichas rutinas enviando parmetros y recibiendo la respuesta respectiva. Un servicio Web se puede considerar como una rutina a la cual se le envan los parmetros utilizando XML encapsulados en el protocolo HTTP. 1.3 Qu es una aplicacin Web? El trmino aplicacin Web [3, 23] ha ido evolucionando desde un pequeo sitio Web a una robusta y entera aplicacin. Ahora ya no es raro entender por una aplicacin Web a cientos de usuarios simultneos, distribuidos alrededor del mundo, todos conectados a la vez si se requiere. Este trmino vara de acuerdo a las personas, algunos creen que una aplicacin Web es cualquier pgina que use java, otros consideran cualquier sistema que use un servidor Web. Aqu, una aplicacin Web, ser un servidor Web en el cual los usuarios introducen datos que afectan la condicin del negocio. La diferencia entre una aplicacin Web y un sitio Web radica en su uso. Una aplicacin Web implementa la lgica del negocio, y usa cambios de estados del negocio. As, las aplicaciones Web son sistemas de informacin donde una gran cantidad de datos voltiles, altamente estructurados, son consultados, procesados y actualizados mediante navegadores. [9] El diseo de su interfaz est condicionado por las necesidades de claridad y simplicidad. Debe tener una estructura que oriente a cada tipo de usuario en funcin de sus necesidades. [9] La arquitectura de una pgina Web [3, 12] (Ver figura 1.2) no es muy diferente de un sitio Web dinmico. En muchas situaciones la dimensin de la lgica del negocio es ejecutada detrs de un servidor Web en uno de las hileras del lado del servidor. La eleccin del lenguaje de modelado y la notacin tpicamente es decidida por las necesidades de este lado de la aplicacin.

Figura 1.2 Arquitectura de Sitio Web dinmico La arquitectura bsica de una aplicacin Web [3, 12] incluye browser, network, y un servidor Web (Ver figura 1.3). Algunas pginas incluyen scripts del lado del cliente que son interpretados por el browser con los cuales el usuario interacta. A veces el usuario ingresa informacin en los campos de los formularios de la pgina y somete estos datos al procesamiento del servidor.

Figura 1.3 Arquitectura bsica de las aplicaciones Web Actualmente los servidores Web son mucho ms seguros, e incluyen caractersticas, como la administracin de usuarios, el estado del servidor, proceso de la transaccin, administracin remota, etc. Hoy en da los servidores Web pueden ser divididos dentro de tres categoras: pginas con cdigo (scripts, ejecutable del lado del servidor), pginas compiladas (carga y ejecuta un componente binario) y un hbrido entre los dos. Esta ultima categora representa pginas con cdigo, que una vez que son solicitadas son compiladas y usadas en lo sucesivo con esta misma compilacin cuentas veces se requiera. 1.4 Por qu usar metodologas en el desarrollo de aplicaciones Web? El desarrollo de aplicaciones Web [19] involucra decisiones no triviales de diseo e implementacin que inevitablemente influyen en todo el proceso de desarrollo, afectando la divisin de tareas. Los problemas involucrados, como el diseo del modelo del dominio y la construccin de la interfaz de usuario, tiene requerimientos disjuntos que deben ser tratados por separado. El alcance de la aplicacin y el tipo de usuario a los que estar dirigida son consideraciones tan importantes como las tecnologas elegidas para realizar la implementacin. As como las tecnologas pueden limitar la funcionalidad de la aplicacin, decisiones de diseo equivocadas tambin puede reducir su capacidad de

7 usabilidad. El marco [9] de desarrollo de este tipo de aplicaciones debe incluir un proceso general que tenga en cuenta de manera explicita las caractersticas particulares de las aplicaciones Web. Para todo esto se han desarrollado metodologas que permiten estructurar, comunicar, entender, simplificar y formalizar tanto el dominio del problema como las decisiones de diseo, as como disponer de una documentacin detallada y exacta ante futuras modificaciones.

2. UML
2.1 Introduccin a UML Tras la aceptacin del paradigma orientado a objetos [14, 17] como el ms adecuado para producir software de calidad, a principios de los noventas emergieron un buen nmero de mtodos de desarrollo de software OO. En julio de 1993, Jacobson critic en lo que l denominaba guerra de mtodos y plante la necesidad de llegar a una notacin estndar de modelado, para evitar la confusin reinante y favorecer el uso de los mtodos de software OO. A finales de 1994 se inici un esfuerzo de unificacin por parte de los creadores de tres principales mtodos: Booch, Rumbaugh y Jacobson. El Lenguaje Unificado de Modelado (UML) es el resultado de esa colaboracin y de las aportaciones de las principales empresas de software (Ver la figura 2.1).

Figura 2.1 Evolucin de UML UML fue adoptado en noviembre de 1997 por OMG (Object Management Group) como una de sus especificaciones y desde entonces se ha convertido en un estndar de factor para visualizar, especificar y documentar los modelos que se crean durante la aplicacin de un proceso de software. UML ha ejercitado un gran impacto en la comunidad del software, tanto a nivel de desarrollo como de investigacin. Su xito ha sido enorme, como lo prueban, por una parte, su utilizacin en todo el mundo para construir aplicaciones en todos los dominios y de todos los tamaos, y por otra, que los entornos de desarrollo ms extendidos como son los de Borland, Microsoft e IBM integran herramientas para el modelado con UML. Otras dos especificaciones de OMG relacionadas con UML son el lenguaje OCL (Object Constraint Language) y XMI (XML Metadata Interchange). OCL es un lenguaje que se utiliza para escribir expresiones sobre modelos, de modo que extiende la potencia expresiva de UML y permite crear modelos ms precisos y ms completos; XMI es un formato para intercambio de modelos basado en XML (eXtensible Markup Language).

9 El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos significan. Mientras que ha habido muchas notaciones y mtodos usados para el diseo orientado a objetos, ahora los modeladores slo tienen que aprender una nica notacin. UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas [20]. Diagramas de Casos de Uso para modelar los procesos business. Diagramas de Secuencia para modelar el paso de mensajes entre objetos. Diagramas de Colaboracin para modelar interacciones entre objetos. Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. Diagramas de Clases para modelar la estructura esttica de las clases en el sistema. Diagramas de Objetos para modelar la estructura esttica de los objetos en el sistema. Diagramas de Componentes para modelar componentes. Diagramas de Implementacin para modelar la distribucin del sistema.

2.2 reas de trabajo en UML [10] Los principales objetivos en el diseo de UML fueron stos: obtener un lenguaje simple pero suficientemente expresivo, que permitiera modelar aplicaciones en cualquier dominio, obtener un lenguaje legible; puesto que sera un lenguaje utilizado por las personas; y permitir la generacin automtica de cdigo. Para combinar la simplicidad con la aplicabilidad a cualquier dominio, UML incorpora un conjunto de mecanismos de extensibilidad que permiten definir perfiles que lo adaptan a un dominio concreto (aplicaciones Web, CORBA (Common Object Request Broker Architecture), modelado de negocio, EJB (Enterprise Java Bean)). La legibilidad se obtiene mediante diagramas visuales que presentan los modelos. La generacin de cdigo por parte de herramientas exige una definicin formal de UML, que se consigue mediante un metamodelo expresado en un metalenguaje denominado MOF (MetaObject Facility). 2.3 Proceso Unificado (Unified Process, UP) [10] Es una metodologa para definir procesos de software basados en UML definido en Rational, la empresa de sus creadores que fue adquirida por IBM a finales del 2002. En los ltimos aos se ha definido numerosos procesos que se ajustan e los principios del UP: procesos dirigidos por casos de uso, iterativos e incrementales, y centrados en la arquitectura. El proceso ms extendido ha sido el RUP (Rational Unified Process), definido por Rational (Ver la figura 2.2).

10

Figura 2.2 RUP Caractersticas del RUP: Iterativo. Refinamiento sucesivo Controlado. Gestin de requisitos y control de cambios Construccin de modelos Desarrollo de la arquitectura. Componentes de software Conducido por los casos de uso Soporta tcnicas OO. Uso del UML Desarrollo de software basado en componentes Configurable Fomento al control de calidad

Figura 2.3 Fases en el Proceso Unificado 2.4 Descripcin de los diagramas de UML. Diagrama de Casos de Uso [1]: los diagramas de Casos de Uso describen lo que hace un sistema desde el punto de vista de un observador externo, enfatizando el qu ms que el cmo. Plantean escenarios, es decir, lo que pasa cuando alguien interacta con el

11 sistema, proporcionando un resumen para una tarea u objetivo. El siguiente Caso de Uso describe como Carlos va a desayunar (este es su objetivo), para lo que se plantea el escenario de preparar su caf y el pan tostado (Ver la figura 2.4) .

Figura 2.4 Diagrama de Casos de Uso Nivel 1 En los Casos de Uso, los Actores son papeles que determinadas personas u objetos desempean. Se representan mediante un smbolo de un hombre, de modo que en el ejemplo, Carlos es un Actor. Los Casos de Uso se representan por medio de valos y las lneas que unen Actores con Casos de Uso representan una asociacin de comunicacin. Por su puesto, un Caso de Uso puede ser descrito en mayor profundidad. Por ejemplo si tomamos por separado Preparar pan (Ver la figura 2.5) y Preparar caf (Ver la figura 2.6), podemos bajar un nivel de descripcin y llegar a los siguientes Casos de Uso.

Figura 2.5 Diagrama Casos de Uso nivel 2 A Carlos tuesta el pan en la tostadora, despus lo unta con mantequilla y mermelada de fresa y se lo come, posiblemente mojndolo en un caf.

Figura 2.6 Diagrama Casos de Uso nivel 2 B Carlos calienta leche, aade caf y azcar al gusto y se lo bebe. Los Casos de Uso suelen venir delimitados por fronteras o lmites, que definen una separacin entre lo que es realmente la funcionalidad del sistema y los actores que la

12 usan o colaboran en su desempeo. En las figuras, esta separacin viene representada por medio de la caja que encapsula los valos. Los Casos de Uso son acompaados por una explicacin textual que clarifica las posibles cadencias del lenguaje meramente grfico. De esta manera, combinando Casos de Uso y explicacin textual, se puede obtener escenarios no ambiguos, que resultan ideales en la captura de requisitos de usuario, dada su sencillez de comprensin incluso por quien no est familiarizado con UML. Los Casos de Uso se emplean tambin en la preparacin de escenarios de pruebas con que verificar el software una vez ha sido construido. Diagrama de Secuencia [1]: los diagramas de secuencia describen como los objetos del sistema colaboran. Se trata de un diagrama de interaccin que detalla como las operaciones se llevan a cabo, qu mensajes son enviados y cuando, organizado todo en torno al tiempo. El tiempo avanza hacia abajo en el diagrama. Los objetos involucrados en la operacin se listan de izquierda a derecha de acuerdo a su orden de participacin dentro de la secuencia de mensajes (Ver la figura 2.7).

Figura 2.7 Diagrama de Secuencia Las lneas verticales o lneas de la vida representan el tiempo de vida del objeto. La vida del objeto carlos no termina en este diagrama, sin embargo la del objeto tosty s y esto viene representado mediante el aspa al final de su lnea de la vida. Los rectngulos verticales son barras de activacin y representan la duracin de la ejecucin del mensaje. El mensaje Encender, posiblemente implementado mediante la introduccin del enchufe en una toma de pared, tiene una duracin escasa y similar a la de Apagar. No ocurre lo mismo con la llamada al mtodo tostar(), que dura desde la pulsacin del botn de tostar hasta que el pan es retirado de la bandeja y adems interviene la emisin de un aviso cuando el pan est lo suficientemente caliente, a fin de evitar que se queme. Como se puede observar, la accin tostar viene condicionada por la presencia de pan en la bandeja de la tostadora. En UML los corchetes [] expresan condicin y si estn precedidos de un asterisco indican interaccin mientras se cumpla la condicin. Los mensajes que son intercambiados entre los objetos de un diagrama de secuencia pueden ser sncronos o asncronos. Los mensajes asncronos son aquellos tal que el

13 emisor puede enviar nuevos mensajes mientras el original est siendo procesado. El mensaje asncrono ocurre en el tiempo de manera independiente a otros mensajes. Los mensajes sncronos son todo lo contrario, el emisor debe esperar a que termine el tiempo de proceso del mensaje antes de que pueda emitir nuevos mensajes. Diagramas de colaboracin [1]: son otro tipo de diagramas de interaccin, que contienen la misma informacin que los de secuencia, slo que se centran en las responsabilidades de cada objeto, en lugar de en el tiempo en que los mensajes son enviados. Cada mensaje de un diagrama de colaboracin tiene un nmero de secuencia. El primer nivel de la secuencia es 1, y los mensajes que son enviados durante la misma llamada a un mtodo se numeran 1.1, 1.2 y as sucesivamente para tantos niveles como sea necesario.

Figura 2.8 Diagrama de Colaboracin Diagramas de estados [1]: muestran los posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado. El estado de un objeto depende de la actividad que est llevando a cabo o de alguna condicin. Las transiciones son las lneas que unen los diferentes estados. En ellas se representa la condicin que provoca el cambio, seguida de la accin oportuna separada por /. En un estado en que el objeto esta pendiente de algn tipo de validacin que dependa de un proceso en curso, no es necesario evento externo alguno para que se produzca la transicin, ya que sta ocurrir cuando termine el proceso, en funcin del resultado de ste. En estos casos es conveniente, por claridad, incluir la condicin que de la que depende la transicin (entre corchetes). Los estados inicial, a partir del que se entra en la mquina de estados, y final, que indica que la mquina de estados termina, no tienen otro significado adicional, son elementos ornamentales y se representan mediante un circulo negro y un circulo negro resaltado respectivamente. Los estados de un diagrama de estados pueden anidarse, de forma que los estados relacionados pueden ser agrupados en un estado compuesto. Esto puede ser necesario cuando una actividad involucra sub-actividades asncronas o concurrentes.

Figura 2.9 Mquina de Estados, estados simples

14

Diagramas de actividades [1]: son bsicamente diagramas de flujo adornados, que guardan mucha similitud con los diagramas de estados. Mientras que los diagramas de estados centran su atencin en el proceso que est llevando a cabo un objeto, los diagramas de actividades muestran como las actividades fluyen y las dependencias entre ellas. Los diagramas de actividades pueden dividirse en calles que determinan qu objeto es responsable de qu actividad. Las actividades vienen unidas por transiciones, que pueden separarse en ramas en funcin del resultado de una condicin expresada entre corchetes. Cada rama muestra la condicin que debe ser satisfecha para que el flujo opte por ese camino. Igualmente, las transiciones se pueden bifurcarse en dos o ms actividades paralelas.

Figura 2.10 Diagrama de Actividades Diagramas de clases [1]: muestran un resumen del sistema en trminos de sus clases y las relaciones entre ellas. Son diagramas estticos que muestran qu es lo que interacta, pero no cmo interacta o qu pasa cuando ocurre la interaccin. El siguiente diagrama (Ver la figura 2.11) modela los pedidos de un cliente a una tienda de venta por catlogo. La clase principal es Pedido, asociada a un cliente, una forma de pago y un conjunto de artculos.

15

Figura 2.11 Diagrama de Clases Diagramas de objetos [1]: son anlogos a los de clases, con la particularidad de que en lugar de encontrar clases, encontramos instancias de stas. Son tiles para explicar partes pequeas del modelo en las que hay relaciones complejas. Diagramas de componentes [1]: son mdulos de cdigo, as que los diagramas de componentes vienen a ser los anlogos fsicos a los diagramas de clases. Muestran como est organizado un conjunto de componentes y las dependencias que existen entre ellos.

Figura 2.12 Diagrama de componentes

16 Diagramas de despliegue [1]: los diagramas de despliegue sirven para modelar la configuracin hardware del sistema, mostrando qu nodos lo componen.

Figura 2.13 Diagrama de despliegue.

17

3. METODOLOGAS DE DESARROLLO DE APLICACIONES WEB

3.1 Introduccin al desarrollo de aplicaciones Web El proceso de desarrollo de un sistema [7], sea o no para la Web, se enfrenta al problema de la identificacin de requisitos o requerimientos. La definicin de las necesidades del sistema es un proceso complejo pues en l hay que identificar los requisitos que el sistema debe cumplir para satisfacer las necesidades de los usuarios finales y de los clientes. Para realizar este proceso, no existe una nica tcnica estandarizada y estructurada que ofrezca un marco de desarrollo que garantice la calidad del resultado. Existe en cambio un conjunto de tcnicas, cuyo uso proponen diferentes metodologas para el desarrollo de aplicaciones Web. Se debe tener en cuenta que la seleccin de las tcnicas y el xito de los resultados que se obtengan dependen en gran medida tanto del equipo de anlisis y desarrollo como de los propios clientes o usuarios que en ella participen. Es necesario tener estndares que regulen la creacin de aplicaciones Web. Esto permite la comunicacin entre componentes y sistemas construidos por distintos desarrolladores y ejecutados en distintas plataformas. El marco de desarrollo de este tipo de aplicaciones debe incluir un proceso general que tenga en cuenta de manera explicita las caractersticas particulares de las aplicaciones Web. Las distintas metodologas se pueden dividir en tres generaciones, en base a su nivel de sofisticacin, y en dos familias, las derivadas de modelos clsicos de datos (E/R) y las derivadas de modelos Orientados a Objetos (OMT y UML). La primera generacin: (primera mitad de los 90s). Sienta las bases de la Ingeniera Web al incluir conceptos como constructores de navegacin, o promover la separacin entre estructuras de navegacin y el contenido durante el proceso de desarrollo. La segunda generacin: (segunda mitad de los 90s). Refina los primeros modelos e incluye conceptos como los soportes de funcionalidad bsica, y los primeros esbozos de proceso donde se delimitan los modelos conceptual, lgico y fsico. La tercera generacin: (2000-2002). Profundiza en el soporte para la funcionalidad, se enfatiza el artculo del usuario en los mtodos, y se producen avances hacia la estandarizacin de notaciones, procesos y lenguajes textuales de especificacin. Debido al gran auge que ha tenido en el mbito mundial el uso y navegacin por Internet y la economa electrnica, los diseadores de sitios Web y quienes los contratan para la construccin de sus portales, se han preocupado por las razones que implican que un usuario regrese o no al sitio; pues en el comercio electrnico, el usuario primero se enfrenta a la usabilidad y despus hace el pago. La evaluacin o diagnstico de usabilidad consiste en las metodologas que miden los aspectos de usabilidad de una interfaz utilizada por un sistema e identificar problemas especficos; siendo una parte importante del proceso total del diseo de la interfaz de usuario, que consiste en ciclos iterativos de disear, de prototipos y de la evaluacin.

18 No obstante la popularidad de UML, no se han contemplado la inclusin de caractersticas para el desarrollo en Web, tanto as que ha surgido una nueva rama de la ingeniera de software denominada Ingeniera Web [21], en la cual se trata de cubrir los aspectos importantes de las aplicaciones enfocadas a la Web. 3.2 UWE (Ingeniera Web basada en UML) La ingeniera Web basada en UML (UWE) fue presentada por Nora Koch [14] en el 2000. Esta metodologa utiliza un paradigma orientado a objetos, y est orientada al usuario. Est basada en los estndares UML y UP (Proceso Unificado), cubre todo el ciclo de vida de este tipo de aplicaciones centrando adems su atencin en aplicaciones personalizadas. UWE propone una extensin de UML que se divide en 4 pasos [9]: 1. Anlisis de requisitos. Su objetivo es encontrar los requisitos funcionales de la aplicacin Web para representarlos como casos de uso. Da lugar a un diagrama de casos de uso. 2. Diseo conceptual. Su objetivo es construir un modelo conceptual del dominio de la aplicacin considerando los requisitos reflejados en los casos de uso. Da como resultado un diagrama de clases de dominio. 3. Diseo navegacional. Se obtienen el modelo de espacio de navegacin y modelo de estructura de navegacin, que muestra cmo navegar a travs del espacio de navegacin. Se obtienen diagramas de clases que representan estos modelos. 4. Diseo de presentacin. De este paso se obtienen una serie de vistas de interfaz de usuario que se presentan mediante diagramas de interaccin UML. La figura 3.1 muestra los modelos representados por paquetes relacionados mediante dependencias en UML.

Figura 3.1 Modelo por paquetes Los aspectos principales de esta metodologa son: 1. Uso de una notacin estndar, como es la notacin UML. 2. Definicin precisa del mtodo, una serie de pasos para seguir la construccin de los modelos.

19 3. La especificacin de restricciones, la metodologa recomienda el uso de restricciones escritas en el Lenguaje de Restricciones de Objetos (OCL) para aumentar la precisin de los modelos. 3.3 WAE (Extensin de Aplicaciones Web para UML) [3] UML tiene definido un mecanismo para permitir cierto dominio para extender la semntica del modelo de elementos especficos, el mecanismo de extensin permite incluir nuevos atributos, diferente semntica y restricciones adicionales. El conjunto de extensin de UML propuesto por Jim Conallen esta formado por Valores etiquetados, estereotipos y restricciones (Tagged Values, Stereotypes and Constraints). La parte del mecanismo de la extensin de UML es la habilidad de asignar iconos diferentes a las clases estereotipadas. El problema de una pgina Web es que tiene diferentes scripts y variables que se ejecutan en el servidor o del lado del cliente, este problema se puede resolver de dos formas: El primero sera definir los estereotipos [4] (Ver la figura 3.2); mtodo del servidor y mtodo del cliente. En un objeto de la pgina un mtodo que ejecuta en el servidor se estereotipar como server method y las funciones que corren en el cliente client method. Esto resuelve el problema de distinguir los atributos y mtodos de un objeto de la pgina, sin embargo todava es un poco confuso. Una complicacin extensa se levanta despus cuando se hacen asociaciones a otros componentes en el modelo. No est claro que algunas de estas relaciones slo son vlidas en el contexto de los mtodos y atributos del servidor o en los del cliente.

Figura 3.2 Estereotipos de la Metodologa WAE 3.4. Metodologas Basadas en Hipermedia y Orientadas a Objetos. 3.4.1 Qu es Multimedia? Multimedia: tambin denominada integracin de medios digitales, consiste e un sistema que utiliza informacin almacenada o controlada digitalmente (texto, grficos, animacin, voz y vdeo) que se combinan en la computadora para formar una nica presentacin. La multimedia se pude definir, como una combinacin de informaciones de naturaleza diversa, coordinada por la computadora y con la que el usuario puede interactuar. Se podr emplear para realzar y optimizar el flujo de informacin,

20 incrementando la eficacia de la comunicacin entre el usuario final y la computadora. La utilizacin de medios digitales de forma interactiva permitir crear un entorno de comunicacin ms participativo, ya que combina informacin de diversos medios en una nica corriente de conocimiento, aumentando el impacto que se producira en los usuarios si se emplea de manera separada, los medios digitales que se incluyen en una computadora son Animacin, Grficos, Sonido y Vdeo. 3.4.2 Qu es la Hipermedia? La hipermedia [13] es el resultado de combinacin de hipertexto y la multimedia. Tradicionalmente, la idea de hipertexto se ha asociado con la documentacin puramente textual, o en todo caso grfico, por lo que la inclusin de otros tipos de informacin (vdeo, msica, etc.) suele recogerse con el nombre de hipermedia. Por una parte, el hipertexto permite representar una estructura asociativa en la que nodos o conceptos pueden enlazarse automticamente. Las aplicaciones multimedia permiten integrar diferentes medios bajo una presentacin interactiva, para lo que pueden ofrecer dos tipos de accesos a la informacin: 1. El mecanismo mayoritariamente utilizado, consiste en un control de usuario similar al de un reproductor de vdeo o sonido que avanza siguiendo el eje de coordenadas temporal. 2. En algunos casos, se permite realizar saltos a un determinado instante dentro de una presentacin, como suele hacerse en muchos reproductores de discos compactos. Esta facilidad tan slo permite al usuario que, indicando el momento exacto en que debera aparecer un contenido, se pueda llevar a cabo un rpido movimiento hasta alcanzar dicho punto. A diferencia de los enlaces hipertextuales, estos saltos no dan lugar a ningn tipo de estructura concreta en la que navegar a travs de la informacin. Las ventajas de la hipermedia En primer lugar, la hipermedia ofrece un medio adecuado para representar aquella informacin poco o nada estructurada que no puede ajustarse a los rgidos esquemas de las bases de datos tradicionales. Adems, permite estructurar la informacin, jerrquicamente o no, de tal modo que tambin resulta til en sistemas de documentacin de textos tradicionales que poseen una marcada organizacin. Esta tecnologa, que se caracteriza por sus ergonmicos interfaces de usuario, muy intuitivos, pues imitan el funcionamiento de la memoria humana, hace que el usuario no tenga que realizar grandes esfuerzos para conseguir resultados rpidamente. Estructura de los sistemas Hipermedia Propiedades fundamentales en un sistema hipermedia hoy en da son: 1. El proceso de ligado entre dos tems, dando una elevacin al paradigma bsico de nodo y liga. 2. La seleccin por asociacin, dando una elevacin al soporte de ligas que permite el recorrido de una red de nodos en una manera directa.

21 Un sistema hipermedia esta hecho de nodos (conceptos) y ligas (relaciones). Los nodos estn conectados a otros nodos por ligas. El nodo del cual una liga origina es llamado referencia y el nodo en el cual la liga termina es llamado referente. Ellos son tambin referidos como anclas. El contenido de un nodo es desplegado por ligas activas. Aparte de esta arquitectura nodo-liga, los sistemas hipermedia tienen una estructura irregular. Balasubramanian [22] lista los componentes bsicos de un sistema hipermedia como sigue: 1. Una interfaz de usuario grfica con navegadores y diagramas generales para ayudar a los usuarios a navegar a travs de una gran cantidad de informacin dispersa, posiblemente interconectada, unida por ligas activas. 2. Un sistema con herramientas para crear y manejar nodos y ligas. 3. Mecanismos de recuperacin de informacin tradicional (tales como bsquedas por palabra clave, bsqueda por autor, etc.) 4. Una ingeniera hipermedia para manejar informacin acerca de nodos y ligas. 5. Un sistema de almacenaje el cual puede ser un sistema de archivos o una base de conocimiento o un tradicional DBMS. Diseando Sistemas Hipermedia El proceso de desarrollo de un sistema hipermedia puede ser modelado a un cierto grado sobre los procesos de ingeniera de software. Por ejemplo, disear el modelo de datos conceptual y el modelo abstracto de navegacin puede beneficiarse directamente de las propuestas de ingeniera de software. Las tcnicas de diseo formal perfeccionan la consistencia de los documentos hipermedia y proveen lneas de gua. Sin embargo, para los procesos de ingeniera de software, no se requiere tomar en cuenta aspectos estticos y cognoscitivos, los cuales son dos aspectos importantes del desarrollo hipermedia. Esto implica que las propuestas de ingeniera de software tradicional no son completamente adecuadas para el diseo de sistemas hipermedia. Nanard y Nanard [15] sugiere que las aplicaciones hipermedia pueden ser mejor desarrolladas no siguiendo los pasos secunciales de las metodologas formales tan correctamente. 3.4.3 SOHDM (Metodologa de Diseo Hipermedia Orientado a Objetos y basada en escenarios) Esta propuesta [16] presenta la necesidad de disponer de un proceso que permita capturar las necesidades del sistema. Para ello, propone el uso de escenarios. El proceso de definicin de requisitos parte de la realizacin de un diagrama de contexto tal y como se propone en diagrama de flujos de datos (DFD) de Yourdon [25]. En este diagrama de contexto se identifican las entidades externas que se comunican con el sistema, as como los eventos que provocan esa comunicacin. Las lista de eventos es una tabla que indica en qu eventos puede participar cada entidad. Por cada evento diferente SOHDM propone elaborar un escenario. stos son representados grficamente mediante los denominados SACs (Scenario Activity Chart). Cada escenario describe el proceso de interaccin entre el usuario y el sistema cuando se produce un evento determinado especificando el flujo de actividades, los objetos involucrados y las transacciones realizadas. SOHDM propone un proceso para conseguir a partir de estos escenarios el modelo conceptual del sistema que es representado mediante un diagrama

22 de clases. El proceso de SOHDM contina reagrupando estas clases para conseguir un modelo de clases navegacionales del sistema. 3.4.4 OOHDM (Mtodo de Diseo Hipermedia Orientado a Objetos) OOHDM [19, 24] propone el desarrollo de aplicaciones hipermedia a travs de un proceso compuesto por cuatro etapas: 1. 2. 3. 4. Diseo conceptual Diseo navegacional Diseo de interfaces abstractas Implementacin

Diseo conceptual: durante esta actividad se construye un esquema conceptual representado por los objetos del dominio, las relaciones y colaboraciones existentes establecidas entre ellos. En las aplicaciones hipermedia convencionales, cuyos componentes de hipermedia no son modificados durante la ejecucin, se podra usar un modelo de datos semntica estructural (como el modelo E/R). De este modo, en los casos en que la informacin base pueda cambiar dinmicamente o se intente ejecutar clculos complejos, se necesitar enriquecer el comportamiento del modelo de objetos. En OOHDM el esquema conceptual est construido por clases, relaciones y subsistemas. Las clases son descritas como en los modelos orientados a objetos tradicionales. Sin embargo, los atributos pueden ser de mltiples tipos para representar perspectivas diferentes de las mismas entidades del mundo real. Se usa una notacin similar a UML y tarjetas de clases y relaciones similares a las tarjetas CRC (Clase Responsabilidad Colaboracin). El esquema de las clases consiste en un conjunto de clases conectadas por relaciones. Los objetos son instancias de las clases. Las clases son usadas durante el diseo navegacional para derivar nodos, y relaciones que son usadas para construir enlaces. Diseo navegacional: en OOHDM la navegacin es considerada un paso crtico en el diseo de aplicaciones. Un modelo navegacional es construido como una vista sobre un diseo conceptual, admitiendo la construccin de modelos diferentes de acuerdo con los diferentes perfiles de usuarios. Cada modelo navegacional provee una vista subjetiva del diseo conceptual. En OOHDM existen un conjunto de tipo predefinidos de clases navegacionales: nodos, enlaces y estructuras de acceso. La semntica de los nodos y los enlaces son las tradicionales aplicaciones hipermedia, y las estructuras de acceso, tales como ndices o recorridos guiados, representan los posibles caminos de acceso a los nodos. Los nodos son enriquecidos con un conjunto de clases especiales que permiten de un nodo observar y presentar atributos (incluidos los links), as como mtodos cuando se navega en un particular contexto. Diseo de interfaz abstracta: en OOHDM se utiliza el diseo de interfaz abstracta para describir la interfaz de usuario de aplicacin de hipermedia. El modelo de interfaz ADVs [6] (Vista de Datos Abstracta) especifica la organizacin y comportamiento de la

23 interfaz, pero la apariencia fsica real o de los atributos, y la disposicin de las propiedades de las ADVs. [6] en la pantalla real son hechas en fase de implementacin. Implementacin: en esta fase, el diseador debe implementar el diseo. Hasta ahora, todos los modelos fueron construidos en forma independiente de la plataforma de implementacin; en esta fase es tenido en cuenta el entorno particular en el cual se va a correr la aplicacin. Al llegar a esta fase, el primer paso que debe realizar el diseador es definir los tems de informacin que son parte del dominio del problema. Debe identificar tambin, cmo son organizados los tems de acuerdo con el perfil del usuario y su tarea; decidir qu interfaz debera ver y como debera comportarse. A fin de implementar todo en un entorno Web, el diseador debe decidir adems que informacin debe ser almacenada. 3.4.5 W2000 [2] Supone una propuesta que ampla la notacin UML con conceptos para modelar elementos de multimedia heredados de la propuesta HDM (Mtodo de Diseo Hipermedia). El proceso de desarrollo de W2000 se divide en tres etapas: 1. Anlisis de requisitos. 2. Diseo de hipermedia. 3. Diseo funcional. La especificacin de requisitos en W2000 se divide en dos subactividades: anlisis de requisitos funcionales y anlisis de requisitos navegacionales. La especificacin de requisitos comienza haciendo un estudio de los diferentes roles de usuario que van a interactuar con el sistema. Cada actor potencialmente distinto tendr su modelo de requisitos de navegacin y de requisitos funcionales. El modelo de requisitos funcionales es representado como un modelo de casos de uso tal y como se propone en UML. En l se representa la funcionalidad principal asociada a cada rol y las interacciones que se producen entre el sistema y cada rol. El segundo modelo consiste en otro diagrama de casos de uso pero que no representa funcionalidad sino posibilidades de navegacin de cada actor. La representacin grfica es realizada con una extensin de UML. 3.4.6 EORM (Metodologa de Relaciones de Objetos Mejorada) [13] En esta metodologa, propuesta por D. Lange [5], el proceso de desarrollo de un Sistema de Informacin Hipermedial (Hiperdocumento) comprendera una primera fase de Anlisis Orientada a Objetos del sistema, sin considerar los aspectos hipermediales del mismo, obteniendo un Modelo de Objetos con la misma notacin utilizada en OMT, que refleje la estructura de la informacin (mediante clases de objetos con atributos y relaciones entre las clases) y el comportamiento del sistema (a travs de los mtodos asociados a las clases de objetos). La idea fundamental de esta metodologa es considerar una segunda fase, de Diseo, durante la cual se proceda a modificar el modelo de objetos obtenido durante el anlisis

24 aadiendo la semntica apropiada a las relaciones entre las de objetos para convertirlas en enlaces hipermedia, obteniendo finalmente un modelo enriquecido, que su autor denomina EORM (Enhanced Object-Relationship Model), en el que se refleje tanto la estructura de la informacin (modelo abstracto hipermedial compuesto de nodos y enlaces) como las posibilidades de navegacin ofrecidas por el sistema. Sobre dicha estructura, para lo cual existir un repositorio o librera de clases de enlaces, donde se especifican las posibles operaciones asociadas a cada enlace de un hiperdocumento, que sern de tipo crear, eliminar, atravesar, siguiente, previo etc., as como sus posibles atributos (fecha de creacin del enlace, estilo de presentacin en pantalla, restricciones de acceso, etc.). El desarrollo del Sistema concluira con una ltima fase de Construccin, durante la que se generara el cdigo fuente (por ejemplo en C++) correspondiente a cada clase, y se preparara la Interfaz Grfica de Usuario. La adopcin del enfoque orientado a objetos OMT garantiza todas las ventajas reconocidas para esta tcnica de modelado, como la flexibilidad (posible existencia de mltiples formas de relaciones entre nodos) y la reutilizacin, por la existencia de una librera de clases de enlaces que pueden ser reutilizados en diferentes proyectos de desarrollo hipermedial. Para automatizar la aplicacin de la metodologa EORM, su autor ha desarrollado, en los laboratorios de investigacin de IBM, una herramienta denominada ODMTool que, junto a un generador comercial de Interfaces Grficas de Usuario denominado ONTOS Studio y un Sistema de Gestin de Base de Datos Orientado a Objetos (SGBDOO), permite el diseo interactivo de esquemas EORM y la generacin de cdigo fuente, inicialmente en C++, de las clases incluidas en estos esquemas. El SGBDOO ofrece un repositorio de objetos que permite compartir la informacin de los esquemas entre las herramientas (ODMTool, ONTOS Studio) y las aplicaciones hipermediales desarrolladas. 3.5 Conclusin La inclusin de metodologas para el desarrollo de aplicaciones Web son de vital importancia para obtener un buen producto en ste tipo de aplicaciones. Haciendo una comparacin determinamos que la metodologa WAE es una de las ms completas, esto es porque nos slo se utilizan los diagramas clsicos de UML (diagrama de clases, diagrama de casos de uso, diagrama de secuencia, diagrama de colaboracin, diagrama de estado), sino que la extensin grfica de Jim Conallen es muy entendible con los diferentes estereotipos que se utilizan para realizar aplicaciones Web.

25

4. METODOLOGA WAE PARA EL DESARROLLO DE LAS APLICACIONES WEB PARA UML

4.1 WAE (Extensin de Aplicaciones Web para UML) En la explicacin de lo conceptos Web se utilizara los diagramas e iconos utilizados por Jim Conallen. Ya que Conallen propone una extensin (o estereotipos) a UML para disear aplicaciones Web los cuales se describen a continuacin: Estereotipos [4] Nombre Meta-modelo de clase Descripcin Pgina del servidor Clase Una pgina del servidor representa una pgina Web que tiene scripts que son ejecutadas por el servidor. Estos scripts actan recprocamente con recursos en el servidor (bancos de datos, lgica de negocio, sistemas externos, etc). Los funcionamientos del objeto representan las funciones en el script, y sus atributos representan las variables que son visibles en el alcance de la pgina (accesible por todas las funciones en la pgina).

Icono

Restricciones Valores etiquetados

Las pginas del servidor pueden tener slo relaciones con objetos en el servidor. Artefacto de Scripting - O el lenguaje o artefacto que deben ser uso para ejecutar o interpretar esta pgina (JavaScript, VBScript, Perl, etc.) Pgina del cliente Clase Un caso de una pgina del cliente es una estructura HTML de la pgina Web. Como cualquier pgina HTML es una mezcla de datos, presentacin y lgica igual. Las pginas del cliente son dadas por browsers del cliente, y puede

Nombre Meta-modelo de clase Descripcin

26 contener scripts que son interpretadas por el browser. Las pginas del cliente pueden estar asociaciones con otras pginas del cliente o del servidor. Icono

Restricciones Valores etiquetados

Ninguna TitleTag El ttulo de la pgina como desplegado por el browser. BaseTag El URL de la base para dereferencing URLs relativo. BodyTag El juego de atributos para la etiqueta del <body> que pone el texto de fondo y valor por defecto. Formulario (Form) Clase Una clase estereotipada como un form es una coleccin de campos de entrada que son parte de una pgina del cliente. Una clase del formulario se mapea directamente a HTML. Sus atributos representan los campos de la entrada del formulario de HTML (input boxes, text areas, radio buttons, check boxes, y los campos ocultos). Un form se opera, desde que no pueden encapsularse su funcionamiento en un formulario. Cualquier funcionamiento que acta recprocamente con el formulario sera la propiedad de la pgina que contiene al formulario.

Nombre Meta-modelo de clase Descripcin

Icono

Restricciones Valores etiquetados

Ninguna Mtodo - el mtodo suministra datos a la accin URL, cualquiera GET o POST.

27 Nombre Meta-modelo de clase Descripcin Frame Set Clase Un juego de frames es un contenedor de mltiples pginas Web. La vista de los rectngulos son reas divididas en rectngulos ms pequeos de frames. Cada frame puede ser asociado mediante un solo nombre target aunque no necesariamente. Los contenidos de un frame pueden estar en una pgina Web o en otro juego de frames. Un esteriotipado de la clase de Frame se mapea directamente a una pgina Web, y el HTML enmarca etiqueta. Un frameset es una pgina del cliente, que puede tener funcionamientos y atributos tambin, pero stos slo son activados por browsers que no devuelve frames.

Icono

Restricciones Valores etiquetados

Ninguna Filas (Rows) - El valor del atributo de las filas es la etiqueta <frameset> del HTML. Esto es una secuencia con los hieghts delimitados de la fila. Columnas (Cols) - El valor del atributo del cols es la etiqueta <frameset> del HTML Esto es una secuencia con anchuras de columna delimitadas. Target Clase Tpicamente un target es un marco en una ventana definida por un frameset, sin embargo un target podra ser un completamente de un nuevo caso del browser o ventana. Targeted link las asociaciones especifican targets como el lugar donde una nueva pgina Web ser devuelta.

Nombre Meta-modelo de clase Descripcin

28 Icono

Restricciones

El nombre de un target debe ser nico para cada cliente del sistema. Esto significa eso que slo un caso de un target puede existir en el mismo cliente. Ninguno

Valores etiquetados Nombre Meta-modelo de clase Descripcin

JavaScript Clase En un Javascript permitido por el browser es posible simular a usuario los objetos definidos con funciones del Javascript. Los casos del JavaScript existen solamente en el contexto de las pginas del cliente.

Icono

Restriccin Valores etiquetados

Ninguna Ninguno

Link: un link es un indicador de una pgina del cliente a otra Pgina. En un diagrama de la clase un link es una asociacin entre una pgina del cliente y cualquiera otro pgina del cliente o a una pgina del servidor. Target link: similar a un link la asociacin, un targeted link es un link donde la pgina asociada se da en otro target. Esta asociacin traza directamente a la HTML, con el target especificado por el atributo del target de la etiqueta. Submit: un submit la asociacin siempre es entre un form y una pgina del servidor. Los Forms envan sus valores del campo al servidor a travs de pgina del

29 servidor para procesar. El servidor del Web procesa la pgina del servidor que acepta y usa la informacin en la Form enviada. Esta relacin indica que pgina (o pginas) puede procesar el Form, y qu Forms una pgina del servidor tiene un poco de conocimiento. Builds: el builds la relacin es una relacin especial que conecta el vaci entre el cliente y pginas del servidor. Las pginas del servidor slo existen en el servidor. Ellos son acostumbrados a construir pginas del cliente. El build la asociacin identifica qu pgina del servidor es responsable para la creacin de una pgina del cliente. sta es una relacin direccional, desde que la pgina del cliente no contiene conocimiento de cmo entr en existencia. Una pgina del servidor puede construir mltiples pginas del cliente, pero una pgina del cliente slo puede ser construida a travs de una pgina del servidor. Redirect: un redirect la relacin es una asociacin unidireccional con otra pgina Web. Puede dirigirse los dos al cliente y pginas del servidor. Si la relacin origina de un pgina del servidor entonces indica que el proceso de la demanda de la pgina puede continuar adelante con la otra pgina. Esto siempre indica esa pgina del destino participa en el construccin de una pgina del cliente. Esta relacin en particular no es completamente estructural, desde la invocacin real de un funcionamiento del redireccionamiento debe hacerse programticamente en el cdigo de la pgina originado. Si la relacin se origina de un pgina del cliente entonces esto indica que la pgina del destino ser pedida automticamente por el browser, sin la entrada del usuario. Un valor de retraso de tiempo puede ponerse que especfica un retraso (en segundos) antes de la segunda pgina que se pide. Este uso de redireccionamiento corresponde a la etiqueta de META y HTTP-EQUIV valor de "Refresh". 4.2 Modelado [3] Modelar es muy importante, nos ayuda a manejar la complejidad. Un sistema puede representarse en diferentes formas, con modelos consistentes ya que cada modelo tiene un propsito especfico y pblico. Al modelar es importante que se capture el nivel apropiado de abstraccin y el modelo de los artefactos. 4.2.1 Pginas [3] El componente fundamental de una aplicacin Web es la pgina. Browsers piden pginas (o las pginas conceptuales) de los servidores. Los servidores Web distribuyen pginas de informacin al browsers. La composicin y organizacin de una pgina Web en esencia esta constituida por la interfaz de usuario para la aplicacin. 4.2.2 Servidor Scripting [3] Es importante notar que la conexin entre el cliente y el servidor slo existe durante una peticin de la pgina. Una vez que la peticin se cumple la conexin se rompe. Toda

30 actividad en el servidor (como efectuado por el usuario) ocurre durante la peticin de la pgina. Esto representa una distincin muy significante entre las aplicaciones de servidor de cliente tradicionales. La lgica comercial en el servidor slo es activada por la ejecucin de scripts dentro de las pginas pedidas por el browser. Dependiendo en el artefacto del scripting especfico, las pginas escritas pueden contener al usuario que define variables, sub-rutinas y funciones. Algunos artefactos del scripting incluso permiten la definicin e interaccin de objetos. El ltimo resultado de este servidor a procesar es: 1. Ponga al da el estado comercial del servidor. 2. Prepara un HTML estructurar pgina (interfaz del usuario) para el browser. Una parte importante y sutil parte de la aplicacin Web es entienda y acomodando de este paradigma de cliente y interaccin del servidor. Los objetos comerciales no siempre son accesibles al manejar peticiones de interfaz de usuario individuales. 4.2.3 Cliente Scripting [3] El servidor no es el nico componente en una aplicacin Web que ejecuta scripts. El propio browser puede ejecutar cdigo escrito en una pgina. Cuando el browser ejecuta un script, sin embargo, no tiene acceso directo a los recursos del servidor. Tpicamente scripts que corren en el cliente aumentan la interfaz del usuario como oponerse a definir y llevar a cabo la esencia de la lgica comercial. 4.2.4 Estereotipos de Pginas [3, 12] Una mejor forma de modelar una pgina es separando en dos clases de estereotipos: 1. Pginas del Servidor 2. Pginas del Cliente Cualquier pgina Web dada en una aplicacin Web que tiene funcionalidad en el servidor, as como de lado del cliente puede representarse en el modelo como dos clases separadas, aunque su implementacin est en el mismo archivo (o componente). En esta situacin los mtodos del servidor de una pgina Web y el alcance de variables de la pgina son todos contenidos en una clase en el modelo estereotipado server page (pgina del servidor). Los mtodos de esta clase representan el servidor de la pgina del lado del script; subrutinas y funciones. Una pgina del servidor puede tener relacin a otros componentes que existen en el servidor. La representacin de las pginas del cliente son semejantes en el diagrama de clases estereotipadas: client page (pgina del cliente). Los atributos de pgina del cliente son los alcances de variables de la pgina y funciones que se ejecutan en el browser del cliente. Las pginas del cliente tienen mtodos que se ejecutan solamente del lado del cliente, como por ejemplo, Java Applets y controles ActiveX, y elementos propios del DOM (Modelo de Objeto de Documento) es una forma de representar documentos estructurados (tales como una pgina Web HTML o un documento XML) que es independiente de cualquier lenguaje orientado a objetos.

31

Su finalidad es definir el conjunto de objetos que pueden componer documentos HTML (pginas Web) o XML, as como las estructuras que se definen dentro de l, sus propiedades y sus mtodos, independientemente del lenguaje de programacin utilizado, con el fin de evitar problemas de compatibilidad entre navegadores. Hay una relacin fundamental entre el servidor y el cliente que son estereotipos de una pgina Web. Una pgina del servidor finalmente establece pgina del cliente resultante. Esta es una relacin unidireccional, desde que una pgina de HTML completada tiene acceso pequeo a la interfaz del objeto de la pgina de servidor construida. El estereotipo builds (construir) se aplica a las asociaciones y siempre es arrastrado en el modelo como una asociacin unidireccional de una pgina del servidor a una pgina del cliente. Indica qu pgina del servidor es responsable para construir una pgina del cliente. Por ejemplo (Ver la figura 4.1):

Figura 4.1 Las pginas del servidor construyen las pginas del cliente Algunas pginas del servidor podran redireccionar ciertas solicitudes de procesamiento a otras pginas servidoras (una especie de IF). Permitir modelar estas situaciones es til para la reutilizacin. Para esto se utiliza el estereotipo <<redirects>>. Por ejemplo (Ver la figura 4.2):

Figura 4.2 La Pgina del servidor es la que delega funcionalidad Una parte fundamental entre la relacin de las pginas del cliente y las pginas del servidor estn en el diagrama de implementacin. Los componentes en el diagrama de

32 implementacin representan piezas distribuibles del sistema. Para estos estereotipos es la pgina Web. Un componente en un diagrama de implementacin (vista del componente en Rational Rose) representa un archivo actual que es una demanda por el servidor Web, y qu comprende una pgina del servidor o pgina del cliente por lo menos. La figura 4.3, muestra conceptualmente esta relacin.

Figura 4.3 Unos componentes de pgina Web comprenden servidor y pginas del cliente Una relacin adicional que puede ser de importancia en el diseo de aplicacin Web es el vinculo (link). Las pginas del cliente contienen a menudo vnculos (links o anchors) que unen a otras pginas Web. Estas otras pginas Web o pueden ser servidor o pginas del cliente desde que finalmente es el componente que es pedido por el browser del cliente. Si el componente pedido comprende una pgina del servidor (a lo sumo uno) entonces la pgina del servidor se procesa para conseguir una pgina del cliente resultante para cumplir la demanda del browser. El estereotipo: links se define para las asociaciones entre las pginas del cliente y otras pginas (servidor o cliente). Ver la figura 4.4:

Figura 4.4 Pgina cliente vinculada a otras pginas clientes

33 La decisin de modelar todos links en pginas del cliente queda al diseador, sin embargo, un bueno diseo debe modelar todos links relevantes, para la funcin de la aplicacin. No puede ser necesario modelar hyperlinks a pginas Web fuera del sistema. La asociacin de un links puede ser una asociacin bi-direccional. La relacin de un links en una pgina del servidor no tiene sentido. Si el link incluye parmetros, ellos son modelados como atributos del link fuera de la asociacin, Ver la figura 4.5:

Figura 4.5 Unindose con parmetros 4.3 Componentes [3] Componentes en el sentido de interfaces disponible a los objetos en la aplicacin Web como controles ActiveX y tambin DLLs, Java Applets o executables un estereotipo en la extensin Web. Simplemente con componentes de las pginas que identifican como ejecutarse en la mquina del servidor o en la mquina del cliente. Los estereotipos server component (componente del servidor) y client component (componente del cliente) pueden ser aplicados a las clases en el diseo del modelo para distinguir disponibilidad. Con certeza un componente de acceso de banco de datos en el servidor no es directamente accesible por scritps del cliente que corren en un browser. 4.3.1 Forms (Formularios) [3, 12] Se definen estereotipos adicionales para separar y elaborar Form con el uso de HTML. Los formularios contienen atributos adicionales que no pueden ser apropiados en el contexto de la pgina del cliente. Tambin es posible tener formularios mltiples en una sola pgina, cada targeting en una pgina de accin diferente. Esto puede ser planeado creando una nueva clase estereotipada para representar un solo formulario de HTML; form. Una clase del formulario tiene como atributos los elementos del campo. Los mtodos en una pgina del cliente tienen acceso a todos los atributos de los formularios contenidos dentro de una pgina. La relacin apropiada entre una pgina del cliente y un formulario es su contenido. Las pginas del cliente contienen formularios. Un formulario identifica una pgina Web especfica (casi siempre con un estereotipo de pgina de servidor) aceptar y procesar datos sometidos con el formulario. Un submits

34 es el estereotipo de la asociacin que representa la relacin entre un formulario y la pgina Web que lo procesan, Ver la figura 4.6. La asociacin es bi-direccional desde que la pgina del proceso tiene acceso a los atributos del formulario que se someten cuando la asociacin se comprende durante el runtime.

Figura 4.6 Los formularios hacen un submit a la pgina del servidor 4.3.2 Framesets [3, 12] Una interfaz de usuario adicional (y elemento del diseo) disponible en aplicaciones Web es el frame. Si se usa en una aplicacin, representa una habilidad de presentar pginas Web mltiples al mismo tiempo. Tpicamente estas pginas concurrentes que estn juntas relacionadas representan una sola interfaz de usuario. Los frames se implementan en HTML usando un frameset. Un frameset especifica y opcionalmente los nombres de los frames separados en los que pueden darse pginas Web. La implementacin de un frameset est en una pgina HTML. Una pgina Web de frameset contiene normalmente estructura y contenido informativo que slo se ve en el browsers ms viejo. Esto nos lleva a modelar framesets como una pgina del cliente, pero uno especializado, y de un nuevo estereotipo: "frameset". En un modelo de diseo de clases estereotipar un frameset pueden tener todas las asociaciones que una pgina del cliente puede tener, con la comprensin que stos son slo apropiados para browsers ms viejos.

35 Tpicamente, los framesets contienen pginas del cliente mltiples. Cualquier pgina del cliente puede ser contenida por un frameset. Puesto que un frameset es una especializacin de una pgina del cliente, tambin puede contenerse en un frameset! Actividad coordinanda entre las pginas en frames (u otras ventanas) requiere la habilidad de referenciar pginas dentro de los frames. El Target es el trmino usado cuando una referencias de pgina de cliente a otra pgina Web activa o frame. Desde que los targets representan un elemento muy diferente de un frameset, y considerando las pginas Web pueden tambin referenciar targets que estn en otro browsers abierto, otro estereotipo de la clase se define; "target". Un target no tiene ninguna propiedad o atributos, es meramente un recipiente referenciable para una pgina del cliente. Una clase del frameset puede contener un target, o un target puede existir independientemente (como en el caso de una ventana del browser separada). Las pginas Web contenidas en un frame se llaman targets. El estereotipo <<targeted link>> hace referencia a pginas que van a ser cargadas en un frame distinto del que contiene la pgina que tiene el link. Ver la figura 4.7.

Figura 4.7 Usando framesets y targets.

36

5. PROTOTIPO DE UNA TIENDA VIRTUAL

5.1 Descripcin de la aplicacin Web (Tienda Virtual) a modelar en UML Dentro de los modelos de negocios que existen en el comercio electrnico se presenta la Tienda Virtual dentro del paradigma de Negocios a Clientes (b2c) [8]. El comercio electrnico es una metodologa moderna en el proceso de comercializacin, ayudada por la tecnologa de punta como una nueva maniobra para el desarrollo de una mejor ventaja competitiva. Negocio a Cliente [8]: el cliente puede comparar con la venta al detalle de manera electrnica. Esta categora ha tenido gran aceptacin y se ha ampliado sobre manera gracias al WWW, ya que existen diversos centros comerciales por todo Internet ofreciendo toda clase de bienes de consumo. Lugar Comercial el cual funge la funcin de vender bienes y servicios, a travs del Web, por lo cual est disponible las 24 horas al da, con un alcance global con la habilidad de relacionar y proporcionar informacin al cliente as como rdenes de compra. La Tienda Virtual en su naturaleza se muestra como un servicio dado a travs de una entidad comercial o empresarial en los modelos del comercio electrnico es donde se presentan procesos definidos y capaces de ser automatizados. Y por si fuera poco es la unidad administrativa y elemental de los dems modelos de negocios del comercio electrnico [8]. Una Tienda Virtual va ms all de ser un almacn electrnico de los productos de sta, representa una estrategia de negocio, pues las aplicaciones para una mercadotecnia en lnea (marketing on-line) son innumerables, desde la generacin de estadsticas de compra y venta, realizacin de anlisis de comportamiento de mercado, anlisis del cliente, de sus hbitos de consumo, as como la retroalimentacin de los clientes y su autosuficiencia monetaria a travs de publicidad externa la hace una excelente opcin de desarrollo y sobre todo si se busca disear la aplicacin que la gente, administre y presente. Por lo anterior podemos definir una Tienda Virtual como el modelo de negocios de comercio electrnico que consta de aplicaciones de administracin de servicios y procesos de mercadotecnia en lnea con la funcin de vender bienes y servicios. 5.2 Modelando la parte del usuario de la Tienda Virtual El usuario es la persona que va a interactuar con la tienda virtual como lo describen los siguientes pasos: 1. 2. 3. 4. 5. Ve las categoras disponibles en la tienda y sus productos. Elige los productos que desea. Agrega los productos al carrito de compras. Puede eliminar productos que no desee. Concreta la compra mediante la introduccin de sus datos.

37 6. Si no esta inscrito se da de alta. 7. Realiza el pago

Casos de Uso del Usuario:

Figura 5.1 Caso de Uso del Usuario de la Tienda Virtual

38 Diagrama de Secuencia de Usuario:

Figura 5.2 Diagrama de Secuencia del Usuario de la Tienda Virtual

39 Diagrama de Colaboracin del Usuario:

Figura 5.3 Diagrama de Colaboracin del Usuario de la Tienda Virtual

40 Diagrama de los estereotipos del Usuario:

Figura 5.4 Diagrama de estereotipos del Usuario. 5.3 Modelando la parte del administrador de la Tienda Virtual El administrador es otro usuario, el cual se encargara de dar de alta, eliminar y modificar las categoras y productos como lo describen los siguientes puntos: 1. Registra Categoras y sus productos 2. Elimina Categoras y sus productos 3. Modifica Categoras y sus productos

41 Diagrama de Caso de Usos del Administrador:

Figura 5.5 Caso de Uso del Administrador de la Tienda Virtual Diagrama de Secuencia del Administrador:

Figura 5.6 Diagrama de Secuencia del Administrador de la Tienda Virtual

42 Diagrama de Colaboracin del Administrador:

Figura 5.7 Diagrama de Colaboracin del Administrador de la Tienda Virtual Diagrama de los estereotipos del Administrador:

Figura 5.8 Diagrama de estereotipos del Administrador.

43 La figura 5.9 seria la presentacin de la tienda virtual, en la cual podemos identificar en la parte azul, las siguientes ligas: 1. Inicio 2. Administrador 3. Confirmar la entrada En la parte superior de color negro podemos visualizar las categoras que existen en la tienda virtual, las cuales tambin la podemos ver en parte central en la cual tiene el siguiente mensaje Seleccin la categora que desees: En la parte derecha de la pantalla podemos ver un producto el cual si se desea se puede compra dando click en Agregar Artculo.

Figura 5.9 Pgina principal Al seleccionar alguna de las categoras que tiene la tienda virtual no enva a la pgina de productos (Ver figura 5.10) en la cual podemos seleccionar cualquiera de los productos y seleccionar la cantidad que se desee de ese artculo y dar click en Agregar Artculo y enviarlos al carrito de compras.

44

Figura 5.10 Pgina donde se visualizan los productos. Cuando se envan los productos al carrito de compras podemos ver la figura 5.11 en la cual contiene todos los productos que el usuario ha deseado, el costo unitario de los productos y la suma de los producto la cual se presenta como un subtotal; si algn producto ya no se desea comprar existe la posibilidad de eliminar el producto y se reduce el subtotal. Si ya no se desea comprar ningn producto podemos dar click en Carro Vaci el cual eliminar todos los productos y el carrito de compras quedar vaco; pero si el usuario quiere comprar los productos dar click en Caja.

Figura 5.11 Pgina del carrito de compras Despus de haber dado click en caja debemos confirmar la entrada para confirmar la compra de los productos, al seleccionar la primera opcin es porque ya estamos registrados como usuarios en la tienda virtual, y debemos de ingresar los datos claves que nos pide los cuales son el E-mail y el Password (Ver figura 5.12). Sin el usuario no

45 se ha registrado debe de seleccionar la segunda opcin para darse de alta para las dos opciones debe dar click en Registrar.

Figura 5.12 Confirmacin de datos La figura 5.13 muestra un formulario el cual debe llenarse para darse de alta como usuario de la tienda virtual y poder realizar compras de los productos, al dar click en continuar y si no existe algn error en el llenado del formulario podr ir a la siguiente pgina.

Figura 5.13 Pgina de registro de usuario

46 Despus de haber sido registrado se concretara la compra, los datos de la siguiente pgina (ver figura 5.14) deben ser revisado por el cliente para dar por finalizada la compra.

Figura 5.14 Finalizacin de al compra La figura 5.15 de la pgina es exclusivamente para el administrador en la cual debe ser llenada correctamente, de no ser as no se le dar acceso para modificar la tienda virtual.

Figura 5.15 Administracin

47 Despus de haber ingresado los datos requeridos, no enva a la siguiente pgina (ver figura 5.16) desde la cual podemos elegir la operacin que deseamos realizar (insertar, modificar o eliminar)

Figura 5.16 Mantenimiento de la tienda virtual

48

6. CONCLUSIONES Y PERSPECTIVAS. CONCLUSIONES

En este trabajo se hace una descripcin de cada una de las metodologas utilizadas para realizar aplicaciones Web, haciendo un anlisis de la Extensin de Aplicaciones Web para UML (WAE), es una de las metodologas ms completas por el hecho de la claridad con la que cuenta sus estereotipos (clases) en el diseo de estas aplicaciones, adems de los diagramas habituales de UML. Es por eso que las aplicaciones Web como en los sistemas de informacin es necesario aplicar metodologas, esto es para realizar de una mejor manera y eficientemente ste tipo de aplicaciones. Es por ello que se pretende que se conozca y se utilice la metodologa WAE dando como resultado aplicaciones de calidad. El prototipo de la tienda virtual est realizado con la ayuda de la metodologa WAE, en primer lugar se defini lo que es una tienda virtual y en segundo lugar los diferentes usuarios que intervienen en el prototipo y como interactan; esto es primordial porque no todos los usuarios interactan de la misma forma. La interaccin del usuario de la tienda virtual es eleccin de la categora que se muestran en la tienda y se eligen los productos, los cuales son llevados a un carrito de compra donde se contabiliza los productos y el costo que se debe de pagar. La parte en la que el administrador interacta con la tienda es la parte del mantenimiento (insertar, modificar o eliminar) de sta. El prototipo se realizo con los diagrama que son interactivos (diagrama de casos de usos, diagrama de secuencia y el diagrama de colaboracin) dentro de UML y el diagrama de estereotipos de Jim Conallen, ya que como sabemos que las aplicaciones Web tienen que ser interactivas con los diferentes usuario que consultan este tipo de aplicaciones. El prototipo nos da una pauta para dar como satisfactorio el objetivo general de sta tesis el cual fue: investigar la manera en la que UML puede ser aplicado al desarrollo de aplicaciones Web.

49

PERSPECTIVAS
La perspectiva del prototipo es realizar la parte del pago de la compra, el envi del pedido y conexin que se debe realizar con los bancos, la cual quedara de la siguiente forma:

Figura 6.1 Pago de la orden. UML ha sido desarrollado para responder a los requerimientos del desarrollo de aplicaciones orientadas a objetos tradicionales. Las aplicaciones Web presentan un cierto nmero de particularidades que demandan ciertas adaptaciones de UML con la finalidad de modelar la arquitectura. La perspectiva de la tesis es desarrollar una metodologa para adaptar UML al desarrollo de aplicaciones Web, con la colaboracin de metodologas ya existentes.

50

7. BIBLIOGRAFA
[1] Arregui Miguel. Tutorial de UML, Depto. de lenguajes y sistemas informticos Grupo IRIS (integracin y reingeniera de sistemas), Universidad Jaume I, Castelln, 2004 http://www.seis.es/inforsalud04/2004_Inforsalud_TutorialUML-UP.doc [2] Baresi L., Garzotto F., Paolini P. Extending UML for Modelling Web Applications. In proceedings of the 34th annual Hawaii Internacional Conference on System Science. IEEE Computer Society, 2001 [3] Conallen Jim. Modeling Web Applications with UML, Conallen, Inc., Marzo 1999 http://www.conallen.org/whitepapers/webapps/ModelingWebApplications.htm [4] Conallen Jim. UML Extension for Web Applications 0.91, Conallen, Inc., Marzo 1999 http://www.conallen.org/technologyCorner/webextension/WebExtension091.htm [5] D. B. Lange, "An Object-Oriented Design Approach for Developing Hypermedia Information Systems", Research Report RT0112, IBM Research, Tokyo Research Laboratory, Japn, 1995. [6] D. Cowan and C. Lucena. Abstract Data Views: An Interface Specification Concept to Enhance Design for Reuse. IEEE Transactions on Software Engineering. Vol. 21, No. 3, Marzo 1995. [7] Escalona M. J. y Koch N. Ingeniera de Requisitos en Aplicaciones para la Web: Un estudio Comparativo, 2002 www.pst.informatik.uni-muenchen.de/personen/kochn/ideas03-escalona-koch.pdf [8] Fuentes Quiroz Ivn, Desarrollo de aplicaciones para la construccin de sitios interactivos en Internet para el comercio electrnico, Departamento de Ingeniera en Sistemas Computacionales, Universidad de las Amricas, Puebla. 2001 http://www.pue.udlap.mx/~tesis/lis/fuentes_q_i/capitulo2.pdf [9] Garca De Mateos Juan Jimeno, Herrera Gonzlez Patricia, Prez Lujn M Carmen. Metodologas de desarrollo de aplicaciones Web, 2003/2004 http://alarcos.inf-cr.uclm.es/doc/aplicabbdd/DASBD-UWE.pdf [10] Garca Molina Jess J.1, Moreira Ana2, Rossi Gustavo3. Presentacin UML: el lenguaje estndar para el modelado de software, 1Depto. de Informtica y Sistemas, Universidad de Murcia; 2Depto. de Informtica, Facultad de Ciencias y Tecnologa, Universidad de Nova de Lisboa (Portugal); Facultad de Informtica, Universidad Nacional de La Plata (Argentina), Marzo-Abril 2004 http://www.ati.es/novatica/2004/168/168-4.pdf [11] Grupo de Ingeniera del Software. Introduccin a las aplicaciones Web, Departamento de Lenguaje y Sistemas Informticos. Universidad de Sevilla, Octubre 2004

51 [12] Guerrero Luis A. Modelando Aplicaciones Web con UML, Departamento de Ciencias de la Computacin, Universidad de Chile, Mayo 2001 http://www.dcc.uchile.cl/~luguerre/cc61j/recursos/web-app.ppt [13] Gutirrez Jos A., Hilera Jos R., Martnez Javier, Martnez Jos M. Orientacin a Objetos en la Documentacin Hipermedia, Departamento de Ciencias de la Computacin, Universidad de Alcal de Henares, 1998 http://www.ati.es/gt/LATIGOO/OOp96/Ponen6/atio6p06.html [14] Hennicker Rolf, Koch Nora, Kraus Andreas. The Authoring Process of the UML-based Web Engineering Approach, 2000 [15] J. Nanard y M. Nanard. Hypertext Design Environments and Hypertext Design.Communications of the ACM, 38(8), pp. 49-56, Agosto 1995. [16] Lee, H., Lee, C., Yoo, C. A Scenario-based object-oriented methodology for developing hypermedia information systems. Procesings of 31st Annual Conference on Systems Science. Sprague R. 1998 [17] lycos.com. UML, Marzo 2005 http://usuarios.lycos.es/oopere/uml.htm [18] Mateu Carles. Desarrollo de aplicaciones Web, Universidad Oberta de Catalunya, 1ra. Edicin marzo 2004 http://www.uoc.edu/masters/softwarelibre/esp/materials/Desarrollo_web.pdf [19] Mercerat Brbara, Silva Daro Andrs. Construyendo aplicaciones Web con una metodologa de diseo orientada a objetos, 2002 http://www.unab.edu.co/editorialunab/revistas/rcc/pdfs/r22_art5_c.pdf [20] Popkin Software and Systems. Modelado de Sistemas com UML, 2002 http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemasuml.pdf [21] Pressman Roger S., Adaptado por: Darle Ince Ingeniera del Software. Un enfoque practico 5. Edicin. Mc Graw Hill, 2002 [22] V. Balasubramanian. State of the Art Review on Hypermedia Issues and Applications. Reporte Tcnico, Universidad de Rutgers, Marzo 1994. (Disponible va Web: http://www.isg.sfu.ca/duchier/misc/hypertext_review/index.html) [23] Vidal Aragon Miguel ngel. Diseo de un prototipo de servicios Web para la contratacin de un seguro y del transporte del caf, Laboratorio Nacional de Informtica Avanzada, A.C., Marzo 2003 http://www.lania.mx/biblioteca/rtecnicos/Lania-RT-2003-07/LANIA-RT-2003-07MAVA.pdf. [24] Vilain, P., Schwabe, D., Sieckenius, C. A diagrammatic Tool for Representing User Interaction in UML. Lecture Notes in Computer Science. Proc. UML2000. York, England.

52

[25] Yourdon E. Modern Structured Analysis. Prentice-Hall, 1989 Otros sitios de inters: Aplicaciones Web http://www.eside.deusto.es/grupos/gedi/recursos/apuntes/WebTema0.pdf Modeling Web Application Architectures with UML http://www.uml.org.cn/UMLApplication/pdf/webapps.pdf Modelado de aplicaciones Web con UML http://usuario.cicese.mx/~jburci/Docs/art6.htm Historia de Internet http://csc.azc.uam.mx/internet/manuales/historia.html Una historia de Internet http://www.galeon.com/periodismo-digital/hismontesi.htm