Tes810 Uml

5/10/2018 Tes810 Uml - slidepdf.com

http://slidepdf.com/reader/full/tes810-uml 1/57

PUEBLA, PUE. 2005

BENEMÉRITA UNIVERSIDAD

AUTÓNOMA DE PUEBLA

FACULTAD DE CIENCIAS DE LACOMPUTACIÓN

“DESARROLLO DE APLICACIONES

WEB USANDO UML”

TESIS PROFESIONAL

QUE PARA OBTENER EL TÍTULO DE

LICENCIADO EN CIENCIAS DE LA

COMPUTACIÓN

PRESENTA

ALBERTO LÓPEZ AGUILAR

ASESOR

DR. ABRAHAM SÁNCHEZ LÓPEZ



AGRADECIMIENTOS

Expreso todo mi agradecimiento a mis padres que son parte importante en mi vida e

inspiración para seguir adelante, con todo mi cariño y amor les dedico éste trabajo de

tesis y también a mi hermana Elizabeth López Aguilar que es parte fundamental en la

culminación de esta etapa importante para mi.

De igual forma agradezco al Dr. Abraham Sánchez López, que sin duda sus palabras de

aliento fueron de gran importancia para terminar de una buena manera éste trabajo de

tesis.

También está dedicado a mis profesores de la licenciatura que intervinieron en mi

formación académica.

Y sin duda a mis amigos, amigas y personas que estuvieron en momento de gran

importancia para la culminación de lo que alguna vez fue un sueño y que se volvió

realidad.

A todos:

¡GRACIAS!



I

INDICE

Prefacio

1. Introducción a la Web1.1 Historia de la Web 11.2 Historia de las aplicaciones Web 41.3 ¿Qué es una aplicación Web? 51.4 ¿Por qué usar metodologías en el desarrollo de aplicaciones Web? 6

2. UML2.1 Introducción a UML 82.2 Áreas de trabajo en UML 92.3 Proceso Unificado (Unified Process, UP) 9

2.4 Descripción de los diagramas de UML 103. Metodologías de desarrollo de aplicaciones Web

3.1 Introducción al desarrollo de aplicaciones Web 173.2 UWE (Ingeniería Web basada en UML) 18

3.3 WAE (Extensión de Aplicaciones Web para UML) 193.4 Metodologías Basadas en Hipermedia y Orientadas a Objetos

3.4.1 ¿Qué es Multimedia? 193.4.2 ¿Qué es la Hipermedia? 203.4.3 SOHDM (Metodología de Diseño Hipermedia Orientado a

Objetos y basada en escenarios) 21

3.4.4 OOHDM (Método de Diseño Hipermedia Orientado a Objetos) 223.4.5 W2000 233.4.6 EORM (Metodología de Relaciones de Objetos Mejorada) 23

3.5 Conclusión 24

4. Metodología WAE para el desarrollo de las aplicaciones Web para UML4.1 WAE (Extensión de Aplicaciones Web para UML) 254.2 Modelado 29

4.2.1 Páginas 294.2.2 Servidor Scripting 294.2.3 Cliente Scripting 30

4.2.4 Estereotipos de Páginas 304.3 Componentes 33

4.3.1 Forms (Formularios) 334.3.2 Framesets 34

5. Prototipo de una Tienda Virtual5.1 Descripción de la aplicación Web (Tienda Virtual) a modelar en UML 365.2 Modelando la parte del usuario de la Tienda Virtual 365.3 Modelando la parte del administrador de la Tienda Virtual 40

6. Conclusiones y perspectivas 48

7. Bibliografía 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 metodología para el desarrollo de estas

aplicaciones.

El lenguaje de modelado unificado (UML) es un estándar industrial para describir

diseños. UML no es una metodología, sino un lenguaje. Se basa en las anteriores

especificaciones de BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada

proyecto en un número 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

estática, 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 visión dinámica del sistema. Es decir,

gracias al diseño de la parte dinámica del sistema podemos darnos cuenta en la fase de

diseño 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

representación es limitada, y que ayuda a diseñar un sistema robusto con partes

reutilizables, pero no a solucionar problemas de propagación de mensajes ni de

sincronización o recuperación ante estados de errores. En resumen, un sistema debe

estar bien diseñado, pero también debe funcionar bien.

UML también intenta solucionar el problema de propiedad de código que se da con losdesarrolladores, al implementar un lenguaje de modelado común para todo los

desarrollos se crea una documentación también común, que cualquier desarrollador con

conocimientos de UML será capaz de entender, independientemente del lenguaje

utilizado para el desarrollo.

UML es ahora un estándar, no existe otra especificación de diseño orientado a objetos,

ya que es el resultado de las tres opciones existentes en el mercado. Su utilización es

independiente del lenguaje de programación y de las características de los proyectos, ya

que UML ha sido diseñado para modelar cualquier tipo de proyectos, tanto informáticos

como de arquitectura, o de cualquier otra área.

UML permite la modificación 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 restricción identifica un comportamiento forzado de

una clase o relación, es decir, mediante la restricción estamos forzando el

comportamiento que debe tener el objeto al que se le aplica.

A continuación se realiza un pequeño resumen por capítulo de esta tesina:

En el Capítulo 1 se presenta la historia de Internet y cuales eran el tipo de tecnologías

que se utilizaban para el desarrollo de las aplicaciones Web; además la definición de lo

que es una aplicación Web y la arquitectura de éste tipo de aplicaciones. Se presenta

porque es necesaria la utilización de una metodología para las aplicaciones Web.



III

En el Capítulo 2 presenta el surgimiento de UML, su evolución, áreas de trabajo y un

marco para la definición de software basado en esta notación. Además de la descripción

de los diagramas que conforman a UML.

En el Capítulo 3 se abordan las metodologías que pueden ser utilizadas para el

desarrollo de aplicaciones Web.

En el Capítulo 4 se describe la metodología WAE de una manera extensa y porque ésta

metodología es la más completa para la realización de aplicaciones Web.

En el Capítulo 5 se presenta el prototipo realizado con la metodología WAE.

Finalmente en el Capítulo 6 se presentan las conclusiones de este trabajo.



1

1. INTRODUCCIÓN A LA WEB

1.1 Historia de la Web

Internet [18], la red de redes, nace a mediados de la década de los setentas, bajo los

auspicios de DARPA, la Agencia de Proyectos Avanzados para la Defensa de EstadosUnidos. DARPA inicio un programa de investigación de técnicas y tecnologías paraunir diversas redes de conmutación de paquetes, permitiendo así a las computadorasconectadas a estas redes comunicarse entre sí de forma fácil y transparente.

De estos proyectos nació un protocolo de comunicación de datos, IP o Internet Protocol,que permitía a computadoras diversas comunicarse a través de una red, Internet,formada por la interconexión de diversas redes.

A mediados de los ochentas la Fundación 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 (Departmentof Energy) con la ESNET. En Europa, la mayoría de países disponían de backbonesnacionales (NORDUNET, RedIRIS, SWITCH, etc.) y de una serie de actividades

paneuropeas (EARN y RARE). En esta época aparecen los primeros proveedores deacceso 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 sólo por TCP eIP), algunas de las cuales eran ya de código libre, Internet empezó lo que a mediados del2002 empieza a descender ligeramente el ritmo de crecimiento.

A mediados de los noventas se inició el boom de Internet. En esa época el número de proveedores de acceso privado se disparó, permitiendo a millones de personas acceder aInternet, que a partir de ese momento ya se empezó a conocer como la Red,desbancando a las demás redes de comunicación existentes (Compuserver,FidoNet/BBS, etc.). El punto de inflexión vino marcado por la aparición deimplementaciones de TCP/IP gratuitas así como por la popularidad y abaratamiento delos medios de acceso cada vez más rápidos. El efecto de todos estos cambios fue comouna “bola de nieve”: a medida que se conectaban más usuarios, los costos se reducían,aparecían más proveedores e Internet se hacía más atractiva y económica, con lo que seconectaban más usuarios.

En estos momentos disponer de una dirección de correo electrónico, de acceso a la Web,etc., ha dejado de ser una novedad para convertirse en algo normal en muchos países delmundo. Por eso las empresas, instituciones, administraciones y demás están migrandorápidamente 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 ligerodescanso experimentado en el ritmo de crecimiento, Internet está destinado a convertirseen una suerte de servicios universal de comunicaciones, permitiendo una comunicaciónuniversal.

La WWW (World Wide Web) [18], se ha convertido, junto con el correo electrónico enel principal caballo de batalla de Internet. Ésta ha dejado de ser una inmensa

“biblioteca” de páginas estáticas 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 Investigación Nuclear),Tim Berners-Lee empezó a diseñar un sistema para hacer accesible fácilmente la

información del CERN. Dicho sistemas empleaba el hipertexto para estructurar una redde enlaces entre los documentos. Una vez obtenida la aprobación para continuar el proyecto, nació el primer navegador Web, llamado WorldWideWeb.

En 1992 el sistema ya se había extendido fuera del CERN. El número de servidores“estables” había aumentado, alcanzando la sorprendente cifra de veintiséis. A partir deeste punto, el crecimiento es espectacular.

En 1993 fue el lanzamiento de Mosaic, un navegador para X-Windows que con eltiempo se convertiría en Netscape y que fue un factor clave de popularidad de la Web.En 1994 se fundó la WWW Consortium, que se convertiría en el motor de desarrollo de

los estándares predominantes en la Web. A partir de ese momento, el crecimiento ya fueconstante, convirtiéndose hacia finales de los noventas en el servicio insignia de Internety dando lugar al crecimiento imparable de los servicios en línea que estamosexperimentando actualmente.

El éxito espectacular de la Web se basa en dos puntales fundamentos: el protocoloHTTP y el lenguaje HTML. Uno permite una implantación simple y sencilla de unsistema de comunicaciones que nos permite enviar cualquier tipo de ficheros de unaforma fácil, simplificando el funcionamiento del servidor y permitiendo que servidores

poco potentes atiendan miles de peticiones y reduzcan los costos de despliegue. El otronos proporciona un mecanismo de composición de páginas enlazadas simple y fácil,altamente eficiente y de uso muy simple.

El protocolo HTTP (Hypertext Transfer Protocol) [11, 18] es el protocolo base de laWWW. Se trata de un protocolo simple, orientado a conexión y sin estado. La razón deque esté orientado a conexión es que emplea para su funcionamiento un protocolo decomunicaciones (TCP, transport control protocol) de modo conectado, un protocolo queestablece un canal de comunicaciones de extremo a extremo (entre el cliente y elservido) por el que pasa el flujo de bytes que constituyen los datos que hay quetransferir, en contraposición a los protocolos de datagrama o no orientados a conexiónque dividen los datos en pequeños paquetes (datagramas) y los envían, pudiendo llegar

por vías diferentes del servidor al cliente. El protocolo no mantiene estado, es decir,cada transferencia de datos es una conexión independiente de la anterior sin relaciónalguna entre ellas, hasta el punto de que para transferir un página Web tenemos queenviar código HTML del texto, así como las imágenes que la componen, pues en laespecificación inicial de HTTP, la 1.0, se abrían y usaban tantas conexiones comocomponentes tenía la página, transfiriéndose por cada conexión un componente (el textode la página o cada una de las imágenes).

Existe una variante de HTTP llamada HTTPS (S por secure) que utiliza el protocolo deseguridad SSL (secure socket layer) para cifrar y autenticar el tráfico entre cliente yservidor, siendo ésta muy usada por los servidores Web de comercio electrónico, así

como por aquellos que contienen información personal o confidencial.



3

De manera esquemática, el funcionamiento de HTTP [11,18] es el siguiente: el clienteestablece una conexión TCP hacia el servidor, hacia el puerto HTTP (o el indicado en ladirección de la conexión), envía un comando HTTP de petición de un recurso y por lamisma conexión el servidor responde con los datos solicitados y con algunas cabecerasinformativas (Ver figura 1.1).

Figura 1.1 Arquitectura Cliente/Servidor

El término Cliente/Servidor alude a un procesamiento colaborativo de datos entre dos omás computadoras conectadas en una red.

Los principales componentes de la arquitectura Cliente/Servidor son: clientes,servidores y la infraestructura de comunicación.

Se denomina cliente al proceso que indica el diálogo o solicita los recursos y sedenomina 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: elservidor contiene la parte que debe ser compartida por varios usuarios y el clientecontiene solamente lo particular de cada usuario.

Los clientes interactúan con el usuario usualmente en forma gráfica, frecuentemente secomunican con proceso auxiliares que se encargan de establecer conexión con el

servidor, enviar el pedido, recibir la respuesta, maneja las fallas y realiza actividades desincronización y de seguridad.

Los servidores proporcionan un servicio al cliente y devuelven los resultados, enalgunos casos existen procesos auxiliares que se encargan de recibir las solicitudes delcliente, verificar la protección, activar un proceso servidor para satisfacer el pedido,recibir su respuesta y enviarla al cliente. Una de las más significantes ventajas de unaaplicación Web es el despliegue.

Otro punto importante del éxito de la WWW ha sido el lenguaje HTML (HypertextMark-up Language). Se trata de un lenguaje de marcas que nos permite representar de

forma rica el contenido y también referenciar otros recurso, enlaces a tros documentos



4

(la característica más destacada de la WWW), mostrar formularios para posteriormente procesarlos, etc.

El lenguaje HTML actualmente se encuentra en la versión 4.01 y empieza a proporcionar funcionalidades más avanzadas para crear páginas más ricas en contenido.

Además se ha definido una especificación compatible con HTML, el XHTML(eXtensible Hypertext Markup Language) que suele definir como una versión XMLvalidable de HTML, proporcionándonos un XML Schema contra el que validar eldocumento para comprobar si está bien formado, etc.

1.2 Historia de las aplicaciones Web

Inicialmente la Web era simplemente una colección de páginas estáticas, documentos,etc., que podían consultarse o descargarse. El siguiente paso en su evolución fue lainclusión de un método para confeccionar páginas dinámicas que permitiesen que lomostrado fuese dinámico (generado o calculado a partir de los datos de la petición).

Dichos métodos fueron conocidos como:

CGI (Common Gateway Interface). [18] Y definía un mecanismo mediante el cual podíamos pasar información entre el servidor HTTP y programas externos. Los CGIsiguen siendo muy utilizados, puesto que la mayoría de los servidores Web los soportandebido a su sencillez. Además, nos proporcionan total libertad a la hora de escoger ellenguaje de programación para desarrollarlos.

El esquema de funcionamiento de los CGI tenía un punto débil: cada vez querecibíamos una petición, el servidor Web lanzaba un proceso que ejecutaba el programaCGI. Como, por otro lado, la mayoría de los CGI estaba escrito en algún lenguajeinterpretado (Perl, Python, etc.) o en algún lenguaje que requería run-time environment(Visual Basic, Java, etc.), esto implicaba una gran carga para la máquina del servidor.Además, si la Web tenía muchos accesos al CGI, esto suponía 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 vías. Por unlado se diseñan sistemas de ejecución de módulos más integrados con el servidor, queevitan que éste tenga que instanciar y ejecutar multitud de programas. La otra víaconsiste en dotar al servidor de un intérprete de algún lenguaje de programación(RXML, PHP, VBScript, etc.) que nos permita incluir las páginas en el código demanera que el servidor sea quien lo ejecute, reduciendo así el tiempo de respuesta.

Fast- CGI. Esta es una solución similar al CGI mencionado anteriormente, solo que propone la creación de un solo proceso persistente por cada programa FastCGI en lugar de por cada solicitud del cliente. Es una solución viable pero también tieneinconvenientes de proliferación de procesos en el caso de peticiones concurrentes.

Páginas dinámicas en servidor. Con la aparición de esta tecnología se entra a unanueva forma de trabajo, la cual esta orientada al trabajo del diseñador Web, quien nonecesariamente conocer de lenguajes de programación. Este nuevo enfoque consiste eninsertar pequeños fragmentos de lógica de programación en la estructura HTML de la

página, al contrario de lo que se hacia en los CGIs, que era en el lenguaje de

programación que utiliza sentencias de impresión 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 evolución de los CGIs desarrollada por SUN Microsystems como parte de la tecnología JAVA. De forma general consiste

en la ejecución 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 petición de usuario no se crea un proceso sino un hilo, el cual es mucho maseconómico para el sistema. Esta tecnología 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 más que una técnica parael desarrollo de aplicaciones Web, representa un modelo de computación distribuida

para Internet basado en XML (eXtensible Markup Language). Bajo este concepto ya nosolo se trata la comunicación usuario-aplicación, sino que de manera adicional semaneja la interacción aplicación-aplicación. Para aclarar un poco más el concepto

tomemos como ejemplo una rutina de programación, como sabemos una rutina es comouna caja negra, la cual encierra un proceso y que cumple una función claramentedefinida, luego para construir una aplicación llamamos dichas rutinas enviando

parámetros y recibiendo la respuesta respectiva. Un servicio Web se puede considerar como una rutina a la cual se le envían los parámetros utilizando XML encapsulados enel protocolo HTTP.

1.3 ¿Qué es una aplicación Web?

El término aplicación Web [3, 23] ha ido evolucionando desde un pequeño sitio Web auna robusta y entera aplicación. Ahora ya no es raro entender por una aplicación Web acientos de usuarios simultáneos, distribuidos alrededor del mundo, todos conectados a lavez si se requiere. Este término varía de acuerdo a las personas, algunos creen que unaaplicación Web es cualquier página que use java, otros consideran cualquier sistema queuse un servidor Web. Aquí, una aplicación Web, será un servidor Web en el cual losusuarios introducen datos que afectan la condición del negocio. La diferencia entre unaaplicación Web y un sitio Web radica en su uso. Una aplicación Web implementa lalógica del negocio, y usa cambios de estados del negocio.

Así, las aplicaciones Web son sistemas de información donde una gran cantidad dedatos volátiles, altamente estructurados, son consultados, procesados y actualizados

mediante navegadores. [9]

El diseño de su interfaz está condicionado por las necesidades de claridad y simplicidad.Debe tener una estructura que oriente a cada tipo de usuario en función de susnecesidades. [9]

La arquitectura de una página Web [3, 12] (Ver figura 1.2) no es muy diferente de unsitio Web dinámico. En muchas situaciones la dimensión de la lógica del negocio esejecutada detrás de un servidor Web en uno de las hileras del lado del servidor. Laelección del lenguaje de modelado y la notación típicamente es decidida por lasnecesidades de este lado de la aplicación.



6

Figura 1.2 Arquitectura de Sitio Web dinámico

La arquitectura básica de una aplicación Web [3, 12] incluye browser, network,y un servidor Web (Ver figura 1.3). Algunas páginas incluyen scripts del lado delcliente que son interpretados por el browser con los cuales el usuario interactúa. A vecesel usuario ingresa información en los campos de los formularios de la página y somete

estos datos al procesamiento del servidor.

Figura 1.3 Arquitectura básica de las aplicaciones Web

Actualmente los servidores Web son mucho más seguros, e incluyen características,como la administración de usuarios, el estado del servidor, proceso de la transacción,administración remota, etc. Hoy en día los servidores Web pueden ser divididos dentrode tres categorías: páginas con código (scripts, ejecutable del lado del servidor), páginascompiladas (carga y ejecuta un componente binario) y un híbrido entre los dos. Estaultima categoría representa páginas con código, que una vez que son solicitadas soncompiladas y usadas en lo sucesivo con esta misma compilación cuentas veces serequiera.

1.4 ¿Por qué usar metodologías en el desarrollo de aplicaciones Web?

El desarrollo de aplicaciones Web [19] involucra decisiones no triviales de diseño eimplementación que inevitablemente influyen en todo el proceso de desarrollo,afectando la división de tareas. Los problemas involucrados, como el diseño del modelodel dominio y la construcción de la interfaz de usuario, tiene requerimientos disjuntosque deben ser tratados por separado.

El alcance de la aplicación y el tipo de usuario a los que estará dirigida sonconsideraciones tan importantes como las tecnologías elegidas para realizar la

implementación. Así como las tecnologías pueden limitar la funcionalidad de laaplicación, decisiones de diseño equivocadas también 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 características particularesde las aplicaciones Web.

Para todo esto se han desarrollado metodologías que permiten estructurar, comunicar,

entender, simplificar y formalizar tanto el dominio del problema como las decisiones dediseño, así como disponer de una documentación detallada y exacta ante futurasmodificaciones.



8

2. UML

2.1 Introducción a UML

Tras la aceptación del paradigma orientado a objetos [14, 17] como el más adecuado

para producir software de calidad, a principios de los noventas emergieron un buennúmero de métodos de desarrollo de software OO. En julio de 1993, Jacobson criticó enlo que él denominaba guerra de métodos y planteó la necesidad de llegar a una notaciónestándar de modelado, para evitar la confusión reinante y favorecer el uso de losmétodos de software OO. A finales de 1994 se inició un esfuerzo de unificación por

parte de los creadores de tres principales métodos: Booch, Rumbaugh y Jacobson. ElLenguaje Unificado de Modelado (UML) es el resultado de esa colaboración y de lasaportaciones de las principales empresas de software (Ver la figura 2.1).

Figura 2.1 Evolución de UML

UML fue adoptado en noviembre de 1997 por OMG (Object Management Group) comouna de sus especificaciones y desde entonces se ha convertido en un estándar de factor

para visualizar, especificar y documentar los modelos que se crean durante la aplicaciónde un proceso de software. UML ha ejercitado un gran impacto en la comunidad delsoftware, tanto a nivel de desarrollo como de investigación. Su éxito ha sido enorme,como lo prueban, por una parte, su utilización en todo el mundo para construir aplicaciones en todos los dominios y de todos los tamaños, y por otra, que los entornosde desarrollo más extendidos como son los de Borland, Microsoft e IBM integranherramientas para el modelado con UML. Otras dos especificaciones de OMGrelacionadas 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 más precisos y más completos; XMI es un formato paraintercambio de modelos basado en XML (eXtensible Markup Language).



9

El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramasestándar para modelar sistemas orientados a objetos, y describe la semántica esencial delo que estos diagramas y símbolos significan. Mientras que ha habido muchasnotaciones y métodos usados para el diseño orientado a objetos, ahora los modeladoressólo tienen que aprender una única notación.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software,sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramasen 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 Colaboración 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 estática de las clases en el

sistema.• Diagramas de Objetos para modelar la estructura estática de los objetos en el

sistema.• Diagramas de Componentes para modelar componentes.• Diagramas de Implementación para modelar la distribución del sistema.

2.2 Áreas de trabajo en UML [10]

Los principales objetivos en el diseño de UML fueron éstos: obtener un lenguaje simple pero suficientemente expresivo, que permitiera modelar aplicaciones en cualquier dominio, obtener un lenguaje legible; puesto que sería un lenguaje utilizado por las

personas; y permitir la generación automática de código.

Para combinar la simplicidad con la aplicabilidad a cualquier dominio, UML incorporaun conjunto de mecanismos de extensibilidad que permiten definir perfiles que loadaptan a un dominio concreto (aplicaciones Web, CORBA (Common Object RequestBroker Architecture), modelado de negocio, EJB (Enterprise Java Bean)). La legibilidadse obtiene mediante diagramas visuales que presentan los modelos. La generación decódigo por parte de herramientas exige una definición formal de UML, que se consiguemediante un metamodelo expresado en un metalenguaje denominado MOF (Meta-Object Facility).

2.3 Proceso Unificado (Unified Process, UP) [10]

Es una metodología para definir procesos de software basados en UML definido enRational, la empresa de sus creadores que fue adquirida por IBM a finales del 2002. Enlos últimos años se ha definido numerosos procesos que se ajustan e los principios delUP: procesos dirigidos por casos de uso, iterativos e incrementales, y centrados en laarquitectura. El proceso más extendido ha sido el RUP (Rational Unified Process),

definido por Rational (Ver la figura 2.2).



10

Figura 2.2 RUP

Características del RUP:

• Iterativo. Refinamiento sucesivo• Controlado. Gestión de requisitos y control de cambios• Construcción de modelos• Desarrollo de la arquitectura. Componentes de software• Conducido por los casos de uso• Soporta técnicas 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 Descripción de los diagramas de UML.

Diagrama de Casos de Uso [1]: los diagramas de Casos de Uso describen lo que haceun sistema desde el punto de vista de un observador externo, enfatizando el qué másque el cómo. Plantean escenarios, es decir, lo que pasa cuando alguien interactúa con el



11

sistema, proporcionando un resumen para una tarea u objetivo. El siguiente Caso de Usodescribe como Carlos va a desayunar (este es su objetivo), para lo que se plantea elescenario 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 objetosdesempeñan. Se representan mediante un “símbolo de un hombre”, de modo que en elejemplo, Carlos es un Actor. Los Casos de Uso se representan por medio de óvalos y laslíneas que unen Actores con Casos de Uso representan una asociación de comunicación.Por su puesto, un Caso de Uso puede ser descrito en mayor profundidad. Por ejemplo sitomamos por separado “Preparar pan” (Ver la figura 2.5) y “Preparar café” (Ver lafigura 2.6), podemos bajar un nivel de descripción y llegar a los siguientes Casos deUso.

Figura 2.5 Diagrama Casos de Uso nivel 2 A

“Carlos tuesta el pan en la tostadora, después lo unta con mantequilla y mermelada de fresa y se lo come, posiblemente mojándolo en un café.”

Figura 2.6 Diagrama Casos de Uso nivel 2 B

“Carlos calienta leche, añade café y azúcar al gusto y se lo bebe.”

Los Casos de Uso suelen venir delimitados por fronteras o límites, que definen unaseparación entre lo que es realmente la funcionalidad del sistema y los actores que la



12

usan o colaboran en su desempeño. En las figuras, esta separación viene representada por medio de la caja que encapsula los óvalos. Los Casos de Uso son acompañados por una explicación textual que clarifica las posibles cadencias del lenguaje meramentegráfico. De esta manera, combinando Casos de Uso y explicación textual, se puedeobtener escenarios no ambiguos, que resultan ideales en la captura de requisitos de

usuario, dada su sencillez de comprensión incluso por quien no está familiarizado conUML. Los Casos de Uso se emplean también en la preparación de escenarios de pruebascon que verificar el software una vez ha sido construido.

Diagrama de Secuencia [1]: los diagramas de secuencia describen como los objetosdel sistema colaboran. Se trata de un diagrama de interacción que detalla como lasoperaciones se llevan a cabo, qué mensajes son enviados y cuando, organizado todo entorno al tiempo. El tiempo avanza “hacia abajo” en el diagrama. Los objetosinvolucrados en la operación se listan de izquierda a derecha de acuerdo a su orden de

participación dentro de la secuencia de mensajes (Ver la figura 2.7).

Figura 2.7 Diagrama de Secuencia

Las líneas verticales o “líneas de la vida” representan el tiempo de vida del objeto. Lavida 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 línea de la vida.

Los rectángulos verticales son barras de activación y representan la duración de laejecución del mensaje. El mensaje “Encender”, posiblemente implementado mediante laintroducción del enchufe en una toma de pared, tiene una duración escasa y similar a lade “Apagar”. No ocurre lo mismo con la llamada al método “tostar()”, que dura desde la

pulsación del botón de tostar hasta que el pan es retirado de la bandeja y ademásinterviene la emisión de un aviso cuando el pan está lo suficientemente caliente, a fin deevitar que se queme. Como se puede observar, la acción tostar viene condicionada por la presencia de pan en la bandeja de la tostadora. En UML los corchetes “[]” expresancondición y si están precedidos de un asterisco indican interacción mientras se cumplala condición.

Los mensajes que son intercambiados entre los objetos de un diagrama de secuencia pueden ser síncronos o asíncronos. Los mensajes asíncronos son aquellos tal que el



13

emisor puede enviar nuevos mensajes mientras el original está siendo procesado. Elmensaje asíncrono ocurre en el tiempo de manera independiente a otros mensajes. Losmensajes síncronos son todo lo contrario, el emisor debe esperar a que termine eltiempo de proceso del mensaje antes de que pueda emitir nuevos mensajes.

Diagramas de colaboración [1]: son otro tipo de diagramas de interacción, quecontienen la misma información que los de secuencia, sólo que se centran en lasresponsabilidades de cada objeto, en lugar de en el tiempo en que los mensajes sonenviados. Cada mensaje de un diagrama de colaboración tiene un número de secuencia.El primer nivel de la secuencia es 1, y los mensajes que son enviados durante la mismallamada a un método se numeran 1.1, 1.2 y así sucesivamente para tantos niveles comosea necesario.

Figura 2.8 Diagrama de Colaboración

Diagramas de estados [1]: muestran los posibles estados en que puede encontrarse unobjeto y las transiciones que pueden causar un cambio de estado. El estado de un objetodepende de la actividad que esté llevando a cabo o de alguna condición. Lastransiciones son las líneas que unen los diferentes estados. En ellas se representa lacondición que provoca el cambio, seguida de la acción oportuna separada por “/”. En unestado en que el objeto esta pendiente de algún tipo de validación que dependa de un

proceso en curso, no es necesario evento externo alguno para que se produzca latransición, ya que ésta ocurrirá cuando termine el proceso, en función del resultado deéste. En estos casos es conveniente, por claridad, incluir la condición que de la quedepende la transición (entre corchetes).

Los estados inicial, a partir del que se “entra” en la máquina de estados, y final, queindica que la máquina de estados termina, no tienen otro significado adicional, sonelementos ornamentales y se representan mediante un circulo negro y un circulo negroresaltado respectivamente. Los estados de un diagrama de estados pueden anidarse, deforma que los estados relacionados pueden ser agrupados en un estado compuesto. Esto

puede ser necesario cuando una actividad involucra sub-actividades asíncronas o

concurrentes.

Figura 2.9 Máquina de Estados, estados simples



14

Diagramas de actividades [1]: son básicamente diagramas de flujo adornados, queguardan mucha similitud con los diagramas de estados. Mientras que los diagramas deestados centran su atención en el proceso que está llevando a cabo un objeto, losdiagramas de actividades muestran como las actividades fluyen y las dependencias entre

ellas.

Los diagramas de actividades pueden dividirse en “calles” que determinan qué objeto esresponsable de qué actividad. Las actividades vienen unidas por transiciones, que

pueden separarse en ramas en función del resultado de una condición expresada entrecorchetes.

Cada rama muestra la condición que debe ser satisfecha para que el flujo opte por esecamino. Igualmente, las transiciones se pueden bifurcarse en dos o más actividades

paralelas.

Figura 2.10 Diagrama de Actividades

Diagramas de clases [1]: muestran un resumen del sistema en términos de sus clases ylas relaciones entre ellas. Son diagramas estáticos que muestran qué es lo queinteractúa, pero no cómo interactúa o qué pasa cuando ocurre la interacción.

El siguiente diagrama (Ver la figura 2.11) modela los pedidos de un cliente a una tiendade venta por catálogo. La clase principal es “Pedido”, asociada a un cliente, una formade pago y un conjunto de artículos.



15

Figura 2.11 Diagrama de Clases

Diagramas de objetos [1]: son análogos a los de clases, con la particularidad de que enlugar de encontrar clases, encontramos instancias de éstas. Son útiles para explicar

partes pequeñas del modelo en las que hay relaciones complejas.

Diagramas de componentes [1]: son módulos de código, así que los diagramas decomponentes vienen a ser los análogos físicos a los diagramas de clases. Muestrancomo está organizado un conjunto de componentes y las dependencias que existen entreellos.

Figura 2.12 Diagrama de componentes



16

Diagramas de despliegue [1]: los diagramas de despliegue sirven para modelar laconfiguración hardware del sistema, mostrando qué nodos lo componen.

Figura 2.13 Diagrama de despliegue.



17

3. METODOLOGÍAS DE DESARROLLO DE APLICACIONESWEB

3.1 Introducción 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 identificación de requisitos o requerimientos. La definición de lasnecesidades del sistema es un proceso complejo pues en él hay que identificar losrequisitos que el sistema debe cumplir para satisfacer las necesidades de los usuariosfinales y de los clientes. Para realizar este proceso, no existe una única técnicaestandarizada y estructurada que ofrezca un marco de desarrollo que garantice la calidaddel resultado. Existe en cambio un conjunto de técnicas, cuyo uso proponen diferentesmetodologías para el desarrollo de aplicaciones Web. Se debe tener en cuenta que laselección de las técnicas y el éxito de los resultados que se obtengan dependen en granmedida tanto del equipo de análisis y desarrollo como de los propios clientes o usuariosque en ella participen.

Es necesario tener estándares que regulen la creación de aplicaciones Web. Esto permitela comunicación entre componentes y sistemas construidos por distintos desarrolladoresy ejecutados en distintas plataformas. El marco de desarrollo de este tipo deaplicaciones debe incluir un proceso general que tenga en cuenta de manera explicita lascaracterísticas particulares de las aplicaciones Web.

Las distintas metodologías se pueden dividir en tres generaciones, en base a su nivel desofisticación, y en dos familias, las derivadas de modelos clásicos de datos (E/R) y lasderivadas de modelos Orientados a Objetos (OMT y UML).

La primera generación: (primera mitad de los 90’s). Sienta las bases de la IngenieríaWeb al incluir conceptos como constructores de navegación, o promover la separaciónentre estructuras de navegación y el contenido durante el proceso de desarrollo.

La segunda generación: (segunda mitad de los 90’s). Refina los primeros modelos eincluye conceptos como los soportes de funcionalidad básica, y los primeros esbozos de

proceso donde se delimitan los modelos conceptual, lógico y físico.

La tercera generación: (2000-2002). Profundiza en el soporte para la funcionalidad, seenfatiza el artículo del usuario en los métodos, y se producen avances hacia la

estandarización de notaciones, procesos y lenguajes textuales de especificación.

Debido al gran auge que ha tenido en el ámbito mundial el uso y navegación por Internet y la economía electrónica, los diseñadores de sitios Web y quienes los contratan

para la construcción de sus portales, se han preocupado por las razones que implicanque un usuario regrese o no al sitio; pues en el comercio electrónico, el usuario primerose enfrenta a la usabilidad y después hace el pago.

La evaluación o diagnóstico de usabilidad consiste en las metodologías que miden losaspectos de usabilidad de una interfaz utilizada por un sistema e identificar problemasespecíficos; siendo una parte importante del proceso total del diseño de la interfaz deusuario, que consiste en ciclos iterativos de diseñar, de prototipos y de la evaluación.



18

No obstante la popularidad de UML, no se han contemplado la inclusión decaracterísticas para el desarrollo en Web, tanto así que ha surgido una nueva rama de laingeniería de software denominada “Ingeniería Web [21]”, en la cual se trata de cubrir los aspectos importantes de las aplicaciones enfocadas a la Web.

3.2 UWE (Ingeniería Web basada en UML)

La ingeniería Web basada en UML (UWE) fue presentada por Nora Koch [14] en el2000. Esta metodología utiliza un paradigma orientado a objetos, y está orientada alusuario. Está basada en los estándares UML y UP (Proceso Unificado), cubre todo elciclo de vida de este tipo de aplicaciones centrando además su atención en aplicaciones

personalizadas.

UWE propone una extensión de UML que se divide en 4 pasos [9]:

1. Análisis de requisitos. Su objetivo es encontrar los requisitos funcionales de la

aplicación Web para representarlos como casos de uso. Da lugar a un diagramade casos de uso.

2. Diseño conceptual. Su objetivo es construir un modelo conceptual del dominiode la aplicación considerando los requisitos reflejados en los casos de uso. Dacomo resultado un diagrama de clases de dominio.

3. Diseño navegacional. Se obtienen el modelo de espacio de navegación y modelode estructura de navegación, que muestra cómo navegar a través del espacio denavegación. Se obtienen diagramas de clases que representan estos modelos.

4. Diseño de presentación. De este paso se obtienen una serie de vistas de interfazde usuario que se presentan mediante diagramas de interacción UML.

La figura 3.1 muestra los modelos representados por paquetes relacionados mediantedependencias en UML.

Figura 3.1 Modelo por paquetes

Los aspectos principales de esta metodología son:

1. Uso de una notación estándar, como es la notación UML.2. Definición precisa del método, una serie de pasos para seguir la construcción de

los modelos.



19

3. La especificación de restricciones, la metodología recomienda el uso derestricciones escritas en el Lenguaje de Restricciones de Objetos (OCL) paraaumentar la precisión de los modelos.

3.3 WAE (Extensión de Aplicaciones Web para UML) [3]

UML tiene definido un mecanismo para permitir cierto dominio para extender lasemántica del modelo de elementos específicos, el mecanismo de extensión permiteincluir nuevos atributos, diferente semántica y restricciones adicionales.

El conjunto de extensión de UML propuesto por Jim Conallen esta formado por Valoresetiquetados, estereotipos y restricciones (Tagged Values, Stereotypes and Constraints).La parte del mecanismo de la extensión de UML es la habilidad de asignar iconosdiferentes a las clases estereotipadas. El problema de una página Web es que tienediferentes scripts y variables que se ejecutan en el servidor o del lado del cliente, este

problema se puede resolver de dos formas:

El primero sería definir los estereotipos [4] (Ver la figura 3.2); método del servidor ymétodo del cliente. En un objeto de la página un método que ejecuta en el servidor seestereotipará como «server method» y las funciones que corren en el cliente «clientmethod». Esto resuelve el problema de distinguir los atributos y métodos de un objetode la página, sin embargo todavía es un poco confuso. Una complicación extensa selevanta después cuando se hacen asociaciones a otros componentes en el modelo. Noestá claro que algunas de estas relaciones sólo son válidas en el contexto de los métodosy atributos del servidor o en los del cliente.

Figura 3.2 Estereotipos de la Metodología WAE

3.4. Metodologías Basadas en Hipermedia y Orientadas a Objetos.

3.4.1 ¿Qué es Multimedia?

Multimedia: también denominada integración de medios digitales, consiste e unsistema que utiliza información almacenada o controlada digitalmente (texto, gráficos,animación, voz y vídeo) que se combinan en la computadora para formar una única

presentación. La multimedia se pude definir, como una combinación de informacionesde naturaleza diversa, coordinada por la computadora y con la que el usuario puedeinteractuar. Se podrá emplear para realzar y optimizar el flujo de información,



20

incrementando la eficacia de la comunicación entre el usuario final y la computadora.La utilización de medios digitales de forma interactiva permitirá crear un entorno decomunicación más participativo, ya que combina información de diversos medios enuna única corriente de conocimiento, aumentando el impacto que se produciría en losusuarios si se emplea de manera separada, los medios digitales que se incluyen en una

computadora son Animación, Gráficos, Sonido y Vídeo.

3.4.2 ¿Qué es la Hipermedia?

La hipermedia [13] es el resultado de combinación de hipertexto y la multimedia.Tradicionalmente, la idea de hipertexto se ha asociado con la documentación puramentetextual, o en todo caso gráfico, por lo que la inclusión de otros tipos de información(vídeo, música, etc.) suele recogerse con el nombre de hipermedia. Por una parte, elhipertexto permite representar una estructura asociativa en la que nodos o conceptos

pueden enlazarse automáticamente. Las aplicaciones multimedia permiten integrar diferentes medios bajo una presentación interactiva, para lo que pueden ofrecer dos

tipos de accesos a la información:

1. El mecanismo mayoritariamente utilizado, consiste en un control de usuariosimilar al de un reproductor de vídeo o sonido que avanza siguiendo el eje decoordenadas temporal.

2. En algunos casos, se permite realizar saltos a un determinado instante dentro deuna presentación, como suele hacerse en muchos reproductores de discoscompactos. Esta facilidad tan sólo permite al usuario que, indicando el momentoexacto en que debería aparecer un contenido, se pueda llevar a cabo un rápidomovimiento hasta alcanzar dicho punto. A diferencia de los enlaceshipertextuales, estos saltos no dan lugar a ningún tipo de estructura concreta enla que navegar a través de la información.

Las ventajas de la hipermedia

En primer lugar, la hipermedia ofrece un medio adecuado para representar aquellainformación poco o nada estructurada que no puede ajustarse a los rígidos esquemas delas bases de datos tradicionales. Además, permite estructurar la información,

jerárquicamente o no, de tal modo que también resulta útil en sistemas dedocumentación de textos tradicionales que poseen una marcada organización.

Esta tecnología, que se caracteriza por sus ergonómicos interfaces de usuario, muyintuitivos, pues imitan el funcionamiento de la memoria humana, hace que el usuario notenga que realizar grandes esfuerzos para conseguir resultados rápidamente.

Estructura de los sistemas Hipermedia

Propiedades fundamentales en un sistema hipermedia hoy en día son:

1. El proceso de ligado entre dos ítems, dando una elevación al paradigma básicode nodo y liga.

2. La selección por asociación, dando una elevación 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 nodosestán conectados a otros nodos por ligas. El nodo del cual una liga origina es llamadoreferencia y el nodo en el cual la liga termina es llamado referente. Ellos son tambiénreferidos como anclas. El contenido de un nodo es desplegado por ligas activas. Apartede esta arquitectura nodo-liga, los sistemas hipermedia tienen una estructura irregular.

Balasubramanian [22] lista los componentes básicos de un sistema hipermedia comosigue:

1. Una interfaz de usuario gráfica con navegadores y diagramas generales paraayudar a los usuarios a navegar a través de una gran cantidad de informacióndispersa, posiblemente interconectada, unida por ligas activas.

2. Un sistema con herramientas para crear y manejar nodos y ligas.3. Mecanismos de recuperación de información tradicional (tales como

búsquedas por palabra clave, búsqueda por autor, etc.)4. Una ingeniería hipermedia para manejar información 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.

Diseñando Sistemas Hipermedia

El proceso de desarrollo de un sistema hipermedia puede ser modelado a un cierto gradosobre los procesos de ingeniería de software. Por ejemplo, diseñar el modelo de datosconceptual y el modelo abstracto de navegación puede beneficiarse directamente de las

propuestas de ingeniería de software. Las técnicas de diseño formal perfeccionan laconsistencia de los documentos hipermedia y proveen líneas de guía. Sin embargo, paralos procesos de ingeniería de software, no se requiere tomar en cuenta aspectos estéticosy cognoscitivos, los cuales son dos aspectos importantes del desarrollo hipermedia. Estoimplica que las propuestas de ingeniería de software tradicional no son completamenteadecuadas para el diseño de sistemas hipermedia. Nanard y Nanard [15] sugiere que lasaplicaciones hipermedia pueden ser mejor desarrolladas no siguiendo los pasossecuénciales de las metodologías formales tan correctamente.

3.4.3 SOHDM (Metodología de Diseño Hipermedia Orientado a Objetos y basadaen escenarios)

Esta propuesta [16] presenta la necesidad de disponer de un proceso que permitacapturar las necesidades del sistema. Para ello, propone el uso de escenarios. El procesode definición de requisitos parte de la realización de un diagrama de contexto tal ycomo se propone en diagrama de flujos de datos (DFD) de Yourdon [25]. En estediagrama de contexto se identifican las entidades externas que se comunican con elsistema, así como los eventos que provocan esa comunicación. Las lista de eventos esuna tabla que indica en qué eventos puede participar cada entidad. Por cada eventodiferente SOHDM propone elaborar un escenario. Éstos son representados gráficamentemediante los denominados SACs (Scenario Activity Chart). Cada escenario describe el

proceso de interacción entre el usuario y el sistema cuando se produce un eventodeterminado especificando el flujo de actividades, los objetos involucrados y las

transacciones realizadas. SOHDM propone un proceso para conseguir a partir de estosescenarios el modelo conceptual del sistema que es representado mediante un diagrama



22

de clases. El proceso de SOHDM continúa reagrupando estas clases para conseguir unmodelo de clases navegacionales del sistema.

3.4.4 OOHDM (Método de Diseño Hipermedia Orientado a Objetos)

OOHDM [19, 24] propone el desarrollo de aplicaciones hipermedia a través de un proceso compuesto por cuatro etapas:

1. Diseño conceptual2. Diseño navegacional3. Diseño de interfaces abstractas4. Implementación

Diseño conceptual: durante esta actividad se construye un esquema conceptualrepresentado por los objetos del dominio, las relaciones y colaboraciones existentesestablecidas entre ellos. En las aplicaciones hipermedia convencionales, cuyos

componentes de hipermedia no son modificados durante la ejecución, se podría usar unmodelo de datos semántica estructural (como el modelo E/R). De este modo, en loscasos en que la información base pueda cambiar dinámicamente o se intente ejecutar cálculos complejos, se necesitará enriquecer el comportamiento del modelo de objetos.

En OOHDM el esquema conceptual está construido por clases, relaciones ysubsistemas. Las clases son descritas como en los modelos orientados a objetostradicionales. Sin embargo, los atributos pueden ser de múltiples tipos para representar

perspectivas diferentes de las mismas entidades del mundo real. Se usa una notaciónsimilar a UML y tarjetas de clases y relaciones similares a las tarjetas CRC (ClaseResponsabilidad Colaboración).

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 diseñonavegacional para derivar nodos, y relaciones que son usadas para construir enlaces.

Diseño navegacional: en OOHDM la navegación es considerada un paso crítico en eldiseño de aplicaciones. Un modelo navegacional es construido como una vista sobre undiseño conceptual, admitiendo la construcción de modelos diferentes de acuerdo con losdiferentes perfiles de usuarios. Cada modelo navegacional provee una vista subjetiva deldiseño conceptual.

En OOHDM existen un conjunto de tipo predefinidos de clases navegacionales: nodos,enlaces y estructuras de acceso. La semántica de los nodos y los enlaces son lastradicionales aplicaciones hipermedia, y las estructuras de acceso, tales como índices orecorridos guiados, representan los posibles caminos de acceso a los nodos. Los nodosson enriquecidos con un conjunto de clases especiales que permiten de un nodoobservar y presentar atributos (incluidos los links), así como métodos cuando se navegaen un particular contexto.

Diseño de interfaz abstracta: en OOHDM se utiliza el diseño de interfaz abstracta para describir la interfaz de usuario de aplicación de hipermedia. El modelo de interfaz

ADVs [6] (Vista de Datos Abstracta) especifica la organización y comportamiento de la



23

interfaz, pero la apariencia física real o de los atributos, y la disposición de las propiedades de las ADVs. [6] en la pantalla real son hechas en fase de implementación.

Implementación: en esta fase, el diseñador debe implementar el diseño. Hasta ahora,todos los modelos fueron construidos en forma independiente de la plataforma de

implementación; en esta fase es tenido en cuenta el entorno particular en el cual se va acorrer la aplicación.

Al llegar a esta fase, el primer paso que debe realizar el diseñador es definir los ítems deinformación que son parte del dominio del problema. Debe identificar también, cómoson organizados los ítems de acuerdo con el perfil del usuario y su tarea; decidir quéinterfaz debería ver y como debería comportarse. A fin de implementar todo en unentorno Web, el diseñador debe decidir además que información debe ser almacenada.

3.4.5 W2000 [2]

Supone una propuesta que amplía la notación UML con conceptos para modelar elementos de multimedia heredados de la propuesta HDM (Método de DiseñoHipermedia). El proceso de desarrollo de W2000 se divide en tres etapas:

1. Análisis de requisitos.2. Diseño de hipermedia.3. Diseño funcional.

La especificación de requisitos en W2000 se divide en dos subactividades: análisis derequisitos funcionales y análisis de requisitos navegacionales. La especificación derequisitos comienza haciendo un estudio de los diferentes roles de usuario que van ainteractuar con el sistema. Cada actor potencialmente distinto tendrá su modelo derequisitos de navegación y de requisitos funcionales.

El modelo de requisitos funcionales es representado como un modelo de casos de usotal y como se propone en UML. En él se representa la funcionalidad principal asociada acada 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 representafuncionalidad sino posibilidades de navegación de cada actor. La representación gráficaes realizada con una extensión de UML.

3.4.6 EORM (Metodología de Relaciones de Objetos Mejorada) [13]

En esta metodología, propuesta por D. Lange [5], el proceso de desarrollo de un Sistemade Información Hipermedial (Hiperdocumento) comprendería una primera fase deAnálisis Orientada a Objetos del sistema, sin considerar los aspectos hipermediales delmismo, obteniendo un Modelo de Objetos con la misma notación utilizada en OMT, querefleje la estructura de la información (mediante clases de objetos con atributos yrelaciones entre las clases) y el comportamiento del sistema (a través de los métodosasociados a las clases de objetos).

La idea fundamental de esta metodología es considerar una segunda fase, de Diseño,durante la cual se proceda a modificar el modelo de objetos obtenido durante el análisis



24

añadiendo la semántica apropiada a las relaciones entre las de objetos para convertirlasen enlaces hipermedia, obteniendo finalmente un modelo enriquecido, que su autor denomina EORM (Enhanced Object-Relationship Model), en el que se refleje tanto laestructura de la información (modelo abstracto hipermedial compuesto de nodos yenlaces) como las posibilidades de navegación ofrecidas por el sistema. Sobre dicha

estructura, para lo cual existirá un repositorio o librería de clases de enlaces, donde seespecifican las posibles operaciones asociadas a cada enlace de un hiperdocumento, queserán de tipo crear, eliminar, atravesar, siguiente, previo etc., así como sus posiblesatributos (fecha de creación del enlace, estilo de presentación en pantalla, restriccionesde acceso, etc.).

El desarrollo del Sistema concluiría con una última fase de Construcción, durante la quese generaría el código fuente (por ejemplo en C++) correspondiente a cada clase, y se

prepararía la Interfaz Gráfica de Usuario.

La adopción del enfoque orientado a objetos OMT garantiza todas las ventajas

reconocidas para esta técnica de modelado, como la flexibilidad (posible existencia demúltiples formas de relaciones entre nodos) y la reutilización, por la existencia de unalibrería de clases de enlaces que pueden ser reutilizados en diferentes proyectos dedesarrollo hipermedial.

Para automatizar la aplicación de la metodología EORM, su autor ha desarrollado, enlos laboratorios de investigación de IBM, una herramienta denominada ODMTool que,

junto a un generador comercial de Interfaces Gráficas de Usuario denominado ONTOSStudio y un Sistema de Gestión de Base de Datos Orientado a Objetos (SGBDOO),

permite el diseño interactivo de esquemas EORM y la generación de código fuente,inicialmente en C++, de las clases incluidas en estos esquemas. El SGBDOO ofrece unrepositorio de objetos que permite compartir la información de los esquemas entre lasherramientas (ODMTool, ONTOS Studio) y las aplicaciones hipermedialesdesarrolladas.

3.5 Conclusión

La inclusión de metodologías para el desarrollo de aplicaciones Web son de vitalimportancia para obtener un buen producto en éste tipo de aplicaciones. Haciendo unacomparación determinamos que la metodología WAE es una de las más completas, estoes porque nos sólo se utilizan los diagramas clásicos de UML (diagrama de clases,

diagrama de casos de uso, diagrama de secuencia, diagrama de colaboración, diagramade estado), sino que la extensión gráfica de Jim Conallen es muy entendible con losdiferentes estereotipos que se utilizan para realizar aplicaciones Web.



25

4. METODOLOGÍA WAE PARA EL DESARROLLO DE LASAPLICACIONES WEB PARA UML

4.1 WAE (Extensión de Aplicaciones Web para UML)

En la explicación de lo conceptos Web se utilizara los diagramas e iconos utilizados por Jim Conallen. Ya que Conallen propone una extensión (o estereotipos) a UML paradiseñar aplicaciones Web los cuales se describen a continuación:

Estereotipos [4]

Nombre Página del servidor

Meta-modelode clase

Clase

Descripción Una página del servidor representa una página Web quetiene scripts que son ejecutadas por el servidor. Estosscripts actúan recíprocamente con recursos en el servidor (bancos de datos, lógica de negocio, sistemas externos,etc). Los funcionamientos del objeto representan lasfunciones en el script, y sus atributos representan lasvariables que son visibles en el alcance de la página(accesible por todas las funciones en la página).

Icono

Restricciones Las páginas del servidor pueden tener sólo relaciones conobjetos en el servidor.

Valores

etiquetados

Artefacto de Scripting - O el lenguaje o artefacto que

deben ser uso para ejecutar o interpretar esta página(JavaScript, VBScript, Perl, etc.)

Nombre Página del cliente

Meta-modelode clase

Clase

Descripción Un caso de una página del cliente es una estructura HTMLde la página Web. Como cualquier página HTML es una

mezcla de datos, presentación y lógica igual. Las páginasdel cliente son dadas por browsers del cliente, y puede



26

contener scripts que son interpretadas por el browser.Las páginas del cliente pueden estar asociaciones con otras

páginas del cliente o del servidor.

Icono

Restricciones Ninguna

Valoresetiquetados

TitleTag – El título de la página como desplegado por el browser.

BaseTag – El URL de la base para dereferencing URLsrelativo.BodyTag – El juego de atributos para la etiqueta del<body> que pone el texto de fondo y valor por defecto.

Nombre Formulario (Form)

Meta-modelode clase

Clase

Descripción Una clase estereotipada como un «form» es una colecciónde campos de entrada que son parte de una página delcliente. Una clase del formulario se mapea directamente aHTML. Sus atributos representan los campos de la entradadel formulario de HTML (input boxes, text areas, radio

buttons, check boxes, y los campos ocultos).Un «form» se opera, desde que no pueden encapsularse sufuncionamiento en un formulario. Cualquier funcionamiento que actúa recíprocamente con elformulario sería la propiedad de la página que contiene alformulario.

Icono


Valores

etiquetados

Método - el método suministra datos a la acción URL,

cualquiera GET o POST.



27

Nombre Frame Set

Meta-modelode clase

Clase

Descripción Un juego de frames es un contenedor de múltiples páginasWeb.La vista de los rectángulos son áreas divididas enrectángulos más pequeños de frames. Cada frame puedeser asociado mediante un solo nombre «target» aunque nonecesariamente.Los contenidos de un frame pueden estar en una páginaWeb o en otro juego de frames.Un esteriotipado de la clase de Frame se mapeadirectamente a una página Web, y el HTML enmarca

etiqueta.Un frameset es una «página del cliente», que puede tener funcionamientos y atributos también, pero éstos sólo sonactivados por browsers que no devuelve frames.

Icono


Valoresetiquetados

Filas (Rows) - El valor del atributo de las filas es laetiqueta <frameset> del HTML. Esto es una secuencia conlos hieghts delimitados de la fila.Columnas (Cols) - El valor del atributo del cols es laetiqueta <frameset> del HTML Esto es una secuencia conanchuras de columna delimitadas.

Nombre Target

Meta-modelode clase

Clase

Descripción Típicamente un target es un marco en una ventana definida por un frameset, sin embargo un target podría ser uncompletamente de un nuevo caso del browser o ventana.«Targeted link» las asociaciones especifican targets comoel lugar donde una nueva página Web será devuelta.



28

Icono

Restricciones El nombre de un target debe ser único para cada cliente delsistema. Esto significa eso que sólo un caso de un target

puede existir en el mismo cliente.

Valoresetiquetados

Ninguno

Nombre JavaScript

Meta-modelode clase

Clase

Descripción En un Javascript permitido por el browser es posiblesimular a usuario los objetos definidos con funciones delJavascript. Los casos del «JavaScript» existen solamente enel contexto de las páginas del cliente.

Icono

Restricción Ninguna

Valoresetiquetados

Ninguno

Link: un link es un indicador de una página del cliente a otra «Página». En un diagramade la clase un link es una asociación entre una «página del cliente» y cualquiera otro«página del cliente» o a una «página del servidor».

Target link: similar a un «link» la asociación, un «targeted link» es un link donde la página asociada se da en otro target. Esta asociación traza directamente a la HTML, conel target especificado por el atributo del target de la etiqueta.

Submit: un «submit» la asociación siempre es entre un «form» y una «página del

servidor». Los Forms envían sus valores del campo al servidor a través de «página del



29

servidor» para procesar. El servidor del Web procesa la «página del servidor» queacepta y usa la información en la Form enviada.

Esta relación indica que página (o páginas) puede procesar el Form, y qué Forms una«página del servidor» tiene un poco de conocimiento.

Builds: el «builds» la relación es una relación especial que conecta el vació entre elcliente y páginas del servidor. Las páginas del servidor sólo existen en el servidor. Ellosson acostumbrados a construir páginas del cliente.

El «build» la asociación identifica qué página del servidor es responsable para lacreación de una página del cliente. Ésta es una relación direccional, desde que la páginadel cliente no contiene conocimiento de cómo entró en existencia.

Una página del servidor puede construir múltiples páginas del cliente, pero una páginadel cliente sólo puede ser construida a través de una página del servidor.

Redirect: un «redirect» la relación es una asociación unidireccional con otra páginaWeb. Puede dirigirse los dos al cliente y páginas del servidor. Si la relación origina deun «página del servidor» entonces indica que el proceso de la demanda de la página

puede continuar adelante con la otra página. Esto siempre indica esa página del destino participa en el construcción de una página del cliente. Esta relación en particular no escompletamente estructural, desde la invocación real de un funcionamiento delredireccionamiento debe hacerse programáticamente en el código de la páginaoriginado.

Si la relación se origina de un «página del cliente» entonces esto indica que la páginadel destino será pedida automáticamente por el browser, sin la entrada del usuario. Unvalor de retraso de tiempo puede ponerse que específica un retraso (en segundos) antesde la segunda página que se pide. Este uso de redireccionamiento corresponde a laetiqueta de META y HTTP-EQUIV valor de "Refresh".

4.2 Modelado [3]

Modelar es muy importante, nos ayuda a manejar la complejidad. Un sistema puederepresentarse en diferentes formas, con modelos consistentes ya que cada modelo tieneun propósito específico y público. Al modelar es importante que se capture el nivel

apropiado de abstracción y el modelo de los artefactos.

4.2.1 Páginas [3]

El componente fundamental de una aplicación Web es la página. Browsers piden páginas (o las páginas conceptuales) de los servidores. Los servidores Web distribuyen páginas de información al browsers. La composición y organización de una página Weben esencia esta constituida por la interfaz de usuario para la aplicación.

4.2.2 Servidor Scripting [3]

Es importante notar que la conexión entre el cliente y el servidor sólo existe durante una petición de la página. Una vez que la petición se cumple la conexión se rompe. Toda



30

actividad en el servidor (como efectuado por el usuario) ocurre durante la petición de la página. Esto representa una distinción muy significante entre las aplicaciones deservidor de cliente tradicionales. La lógica comercial en el servidor sólo es activada por la ejecución de scripts dentro de las páginas pedidas por el browser.

Dependiendo en el artefacto del scripting específico, las páginas escritas puedencontener al usuario que define variables, sub-rutinas y funciones. Algunos artefactos delscripting incluso permiten la definición e interacción de objetos.

El último resultado de este servidor a procesar es:

1. Ponga al día el estado comercial del servidor.2. Prepara un HTML estructurar página (interfaz del usuario) para el browser.

Una parte importante y sutil parte de la aplicación Web es entienda y acomodando deeste paradigma de cliente y interacción 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 aplicación Web que ejecuta scripts. El propio browser puede ejecutar código escrito en una página. Cuando el browser ejecutaun script, sin embargo, no tiene acceso directo a los recursos del servidor. Típicamentescripts que corren en el cliente aumentan la interfaz del usuario como oponerse a definir y llevar a cabo la esencia de la lógica comercial.

4.2.4 Estereotipos de Páginas [3, 12]

Una mejor forma de modelar una página es separando en dos clases de estereotipos:

1. Páginas del Servidor 2. Páginas del Cliente

Cualquier página Web dada en una aplicación Web que tiene funcionalidad en elservidor, así como de lado del cliente puede representarse en el modelo como dos clasesseparadas, aunque su implementación esté en el mismo archivo (o componente). En estasituación los métodos del servidor de una página Web y el alcance de variables de la

página son todos contenidos en una clase en el modelo estereotipado «server page»(«página del servidor»). Los métodos de esta clase representan el servidor de la páginadel lado del script; subrutinas y funciones. Una página del servidor puede tener relacióna otros componentes que existen en el servidor.

La representación de las páginas del cliente son semejantes en el diagrama de clasesestereotipadas: «client page» («página del cliente»). Los atributos de página del clienteson los alcances de variables de la página y funciones que se ejecutan en el browser delcliente. Las páginas del cliente tienen métodos que se ejecutan solamente del lado delcliente, como por ejemplo, Java Applets y controles ActiveX, y elementos propios delDOM (Modelo de Objeto de Documento) es una forma de representar documentos

estructurados (tales como una página Web HTML o un documento XML) que esindependiente de cualquier lenguaje orientado a objetos.



31

Su finalidad es definir el conjunto de objetos que pueden componer documentos HTML(páginas Web) o XML, así como las estructuras que se definen dentro de él, sus

propiedades y sus métodos, independientemente del lenguaje de programación utilizado,con el fin de evitar problemas de compatibilidad entre navegadores.

Hay una relación fundamental entre el servidor y el cliente que son estereotipos de una página Web. Una página del servidor finalmente establece página del cliente resultante.

Esta es una relación unidireccional, desde que una página de HTML completada tieneacceso pequeño a la interfaz del objeto de la página de servidor construida.

El estereotipo «builds» («construir») se aplica a las asociaciones y siempre es arrastradoen el modelo como una asociación unidireccional de una página del servidor a una

página del cliente. Indica qué página del servidor es responsable para construir una página del cliente. Por ejemplo (Ver la figura 4.1):

Figura 4.1 Las páginas del servidor construyen las páginas del cliente

Algunas páginas del servidor podrían redireccionar ciertas solicitudes de procesamientoa otras páginas servidoras (una especie de IF). Permitir modelar estas situaciones es útil

para la reutilización. Para esto se utiliza el estereotipo <<redirects>>. Por ejemplo (Ver la figura 4.2):

Figura 4.2 La Página del servidor es la que delega funcionalidad

Una parte fundamental entre la relación de las páginas del cliente y las páginas delservidor están en el diagrama de implementación. Los componentes en el diagrama de



32

implementación representan piezas distribuibles del sistema. Para estos estereotipos esla página Web. Un componente en un diagrama de implementación (vista delcomponente en Rational Rose) representa un archivo actual que es una demanda por elservidor Web, y qué comprende una página del servidor o página del cliente por lomenos. La figura 4.3, muestra conceptualmente esta relación.

Figura 4.3 Unos componentes de página Web comprenden servidor y páginas delcliente

Una relación adicional que puede ser de importancia en el diseño de aplicación Web esel vinculo (link). Las páginas del cliente contienen a menudo vínculos (links o anchors)que unen a otras páginas Web. Estas otras páginas Web o pueden ser servidor o páginasdel cliente desde que finalmente es el componente que es pedido por el browser delcliente.

Si el componente pedido comprende una página del servidor (a lo sumo uno) entoncesla página del servidor se procesa para conseguir una página del cliente resultante paracumplir la demanda del browser.

El estereotipo: «links » se define para las asociaciones entre las páginas del cliente yotras páginas (servidor o cliente). Ver la figura 4.4:

Figura 4.4 Página cliente vinculada a otras páginas clientes



33

La decisión de modelar todos links en páginas del cliente queda al diseñador, sinembargo, un bueno diseño debe modelar todos links relevantes, para la función de laaplicación. No puede ser necesario modelar hyperlinks a páginas Web fuera del sistema.La asociación de un «links » puede ser una asociación bi-direccional. La relación de un«links » en una página del servidor no tiene sentido. Si el link incluye parámetros, ellos

son modelados como atributos del link fuera de la asociación, Ver la figura 4.5:

Figura 4.5 Uniéndose con parámetros

4.3 Componentes [3]

Componentes en el sentido de interfaces disponible a los objetos en la aplicación Webcomo controles ActiveX y también DLLs, Java Applets o executables un estereotipo en

la extensión Web. Simplemente con componentes de las páginas que identifican comoejecutarse en la máquina del servidor o en la máquina del cliente. Los estereotipos«server component» (componente del servidor) y «client component» (componente delcliente) pueden ser aplicados a las clases en el diseño 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 elcontexto de la página del cliente. También es posible tener formularios múltiples en unasola página, cada targeting en una página de acción diferente. Esto puede ser planeadocreando una nueva clase estereotipada para representar un solo formulario de HTML;«form».

Una clase del formulario tiene como atributos los elementos del campo. Los métodos enuna página del cliente tienen acceso a todos los atributos de los formularios contenidosdentro de una página. La relación apropiada entre una página del cliente y un formularioes su contenido. Las páginas del cliente contienen formularios.

Un formulario identifica una página Web específica (casi siempre con un estereotipo de página de servidor) aceptar y procesar datos sometidos con el formulario. Un «submits»



34

es el estereotipo de la asociación que representa la relación entre un formulario y la página Web que lo procesan, Ver la figura 4.6.

La asociación es bi-direccional desde que la página del proceso tiene acceso a losatributos del formulario que se someten cuando la asociación se comprende durante el

runtime.

Figura 4.6 Los formularios hacen un submit a la página del servidor

4.3.2 Framesets [3, 12]

Una interfaz de usuario adicional (y elemento del diseño) disponible en aplicacionesWeb es el frame. Si se usa en una aplicación, representa una habilidad de presentar

páginas Web múltiples al mismo tiempo. Típicamente estas páginas concurrentes queestán juntas relacionadas representan una sola interfaz de usuario.

Los frames se implementan en HTML usando un frameset. Un frameset especifica yopcionalmente los nombres de los frames separados en los que pueden darse páginasWeb. La implementación de un frameset está en una página HTML. Una página Web deframeset contiene normalmente estructura y contenido informativo que sólo se ve en el

browsers más viejo. Esto nos lleva a modelar framesets como una página del cliente, pero uno especializado, y de un nuevo estereotipo: "frameset". En un modelo de diseñode clases estereotipar un frameset pueden tener todas las asociaciones que una páginadel cliente puede tener, con la comprensión que éstos son sólo apropiados para

browsers más viejos.



35

Típicamente, los framesets contienen páginas del cliente múltiples. Cualquier página delcliente puede ser contenida por un frameset. ¡Puesto que un frameset es unaespecialización de una página del cliente, también puede contenerse en un frameset!Actividad coordinanda entre las páginas en frames (u otras ventanas) requiere lahabilidad de referenciar páginas dentro de los frames.

El Target es el término usado cuando una referencias de página de cliente a otra páginaWeb activa o frame. Desde que los targets representan un elemento muy diferente de unframeset, y considerando las páginas Web pueden también referenciar targets que estánen otro browsers abierto, otro estereotipo de la clase se define; "target". Un target notiene ninguna propiedad o atributos, es meramente un recipiente referenciable para una

página del cliente. Una clase del frameset puede contener un target, o un target puedeexistir independientemente (como en el caso de una ventana del browser separada).

Las páginas Web contenidas en un frame se llaman targets. El estereotipo <<targetedlink>> hace referencia a páginas que van a ser cargadas en un frame distinto del que

contiene la página 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 Descripción de la aplicación Web (Tienda Virtual) a modelar en UML

Dentro de los modelos de negocios que existen en el comercio electrónico se presenta la

Tienda Virtual dentro del paradigma de Negocios a Clientes (b2c) [8].

El comercio electrónico es una metodología moderna en el proceso de comercialización,ayudada por la tecnología de punta como una nueva maniobra para el desarrollo de unamejor ventaja competitiva.

Negocio a Cliente [8]: el cliente puede comparar con la venta al detalle de maneraelectrónica. Esta categoría ha tenido gran aceptación y se ha ampliado sobre maneragracias al WWW, ya que existen diversos centros comerciales por todo Internetofreciendo toda clase de bienes de consumo.

Lugar Comercial el cual funge la función de vender bienes y servicios, a través delWeb, por lo cual está disponible las 24 horas al día, con un alcance global con lahabilidad de relacionar y proporcionar información al cliente así como órdenes decompra.

La Tienda Virtual en su naturaleza se muestra como un servicio dado a través de unaentidad comercial o empresarial en los modelos del comercio electrónico es donde se

presentan procesos definidos y capaces de ser automatizados. Y por si fuera poco es launidad administrativa y elemental de los demás modelos de negocios del comercioelectrónico [8].

Una Tienda Virtual va más allá de ser un almacén electrónico de los productos de ésta,representa una estrategia de negocio, pues las aplicaciones para una mercadotecnia enlínea (marketing on-line) son innumerables, desde la generación de estadísticas decompra y venta, realización de análisis de comportamiento de mercado, análisis delcliente, de sus hábitos de consumo, así como la retroalimentación de los clientes y suautosuficiencia monetaria a través de publicidad externa la hace una excelente opción dedesarrollo y sobre todo si se busca diseñar la aplicación que la gente, administre y

presente.

Por lo anterior podemos definir una Tienda Virtual como el modelo de negocios de

comercio electrónico que consta de aplicaciones de administración de servicios y procesos de mercadotecnia en línea con la función 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 lossiguientes pasos:

1. Ve las categorías disponibles en la tienda y sus productos.2. Elige los productos que desea.3. Agrega los productos al carrito de compras.

4. Puede eliminar productos que no desee.5. Concreta la compra mediante la introducción 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 Colaboración del Usuario:

Figura 5.3 Diagrama de Colaboración 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 ymodificar las categorías y productos como lo describen los siguientes puntos:

1. Registra Categorías y sus productos2. Elimina Categorías y sus productos3. Modifica Categorías 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 Colaboración del Administrador:

Figura 5.7 Diagrama de Colaboración 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 presentación de la tienda virtual, en la cual podemos identificar enla parte azul, las siguientes ligas:

1. Inicio2. Administrador

3. Confirmar la entrada

En la parte superior de color negro podemos visualizar las categorías que existen en latienda virtual, las cuales también la podemos ver en parte central en la cual tiene elsiguiente mensaje “Selección la categoría que desees:”

En la parte derecha de la pantalla podemos ver un producto el cual si se desea se puedecompra dando click en “Agregar Artículo”.

Figura 5.9 Página principal

Al seleccionar alguna de las categorías que tiene la tienda virtual no envía a la página de productos (Ver figura 5.10) en la cual podemos seleccionar cualquiera de los productosy seleccionar la cantidad que se desee de ese artículo y dar click en “Agregar Artículo”y enviarlos al carrito de compras.



44

Figura 5.10 Página donde se visualizan los productos.

Cuando se envían los productos al carrito de compras podemos ver la figura 5.11 en lacual 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 algún producto ya no se desea comprar existe la posibilidad de eliminar el producto y sereduce el subtotal. Si ya no se desea comprar ningún producto podemos dar click en“Carro Vació” el cual eliminará todos los productos y el carrito de compras quedarávacío; pero si el usuario quiere comprar los productos dar click en “Caja”.

Figura 5.11 Página del carrito de compras

Después de haber dado click en caja debemos confirmar la entrada para confirmar lacompra de los productos, al seleccionar la primera opción es porque ya estamos

registrados como usuarios en la tienda virtual, y debemos de ingresar los datos clavesque 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 opción para darse de alta para las dosopciones debe dar click en “Registrar”.

Figura 5.12 Confirmación de datos

La figura 5.13 muestra un formulario el cual debe llenarse para darse de alta comousuario de la tienda virtual y poder realizar compras de los productos, al dar click encontinuar y si no existe algún error en el llenado del formulario podrá ir a la siguiente

página.

Figura 5.13 Página de registro de usuario



46

Después de haber sido registrado se concretara la compra, los datos de la siguiente página (ver figura 5.14) deben ser revisado por el cliente para dar por finalizada lacompra.

Figura 5.14 Finalización de al compra

La figura 5.15 de la página 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 Administración



47

Después de haber ingresado los datos requeridos, no envía a la siguiente página (ver figura 5.16) desde la cual podemos elegir la operación 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 descripción de cada una de las metodologías utilizadas pararealizar aplicaciones Web, haciendo un análisis de la Extensión de Aplicaciones Web

para UML (WAE), es una de las metodologías más completas por el hecho de laclaridad con la que cuenta sus estereotipos (clases) en el diseño de estas aplicaciones,además de los diagramas habituales de UML.

Es por eso que las aplicaciones Web como en los sistemas de información es necesarioaplicar metodologías, esto es para realizar de una mejor manera y eficientemente éstetipo de aplicaciones. Es por ello que se pretende que se conozca y se utilice lametodología WAE dando como resultado aplicaciones de calidad.

El prototipo de la tienda virtual está realizado con la ayuda de la metodología WAE, en primer lugar se definió lo que es una tienda virtual y en segundo lugar los diferentesusuarios que intervienen en el prototipo y como interactúan; esto es primordial porqueno todos los usuarios interactúan de la misma forma.

La interacción del usuario de la tienda virtual es elección de la categoría que semuestran en la tienda y se eligen los productos, los cuales son llevados a un carrito decompra donde se contabiliza los productos y el costo que se debe de pagar.

La parte en la que el administrador interactúa con la tienda es la parte delmantenimiento (insertar, modificar o eliminar) de ésta.

El prototipo se realizo con los diagrama que son interactivos (diagrama de casos deusos, diagrama de secuencia y el diagrama de colaboración) dentro de UML y eldiagrama de estereotipos de Jim Conallen, ya que como sabemos que las aplicacionesWeb tienen que ser interactivas con los diferentes usuario que consultan este tipo deaplicaciones.

El prototipo nos da una pauta para dar como satisfactorio el objetivo general de éstatesis el cual fue: investigar la manera en la que UML puede ser aplicado al desarrollo deaplicaciones Web.



49

PERSPECTIVAS

La perspectiva del prototipo es realizar la parte del pago de la compra, el envió del pedido y conexión que se debe realizar con los bancos, la cual quedaría de la siguienteforma:

Figura 6.1 Pago de la orden.

UML ha sido desarrollado para responder a los requerimientos del desarrollo deaplicaciones orientadas a objetos tradicionales. Las aplicaciones Web presentan uncierto número de particularidades que demandan ciertas adaptaciones de UML con lafinalidad de modelar la arquitectura.

La perspectiva de la tesis es desarrollar una metodología para adaptar UML aldesarrollo de aplicaciones Web, con la colaboración de metodologías ya existentes.



50

7. BIBLIOGRAFÍA

[1] Arregui Miguel. “Tutorial de UML”, Depto. de lenguajes y sistemasinformáticos Grupo IRIS (integración y reingeniería de sistemas), UniversidadJaume I, Castellón, 2004

http://www.seis.es/inforsalud04/2004_Inforsalud_TutorialUML-UP.doc

[2] Baresi L., Garzotto F., Paolini P. “Extending UML for Modelling WebApplications”. In proceedings of the 34th annual Hawaii Internacional Conferenceon System Science. IEEE Computer Society, 2001

[3] Conallen Jim. “Modeling Web Applications with UML”, Conallen, Inc., Marzo1999http://www.conallen.org/whitepapers/webapps/ModelingWebApplications.htm

[4] Conallen Jim. “UML Extension for Web Applications 0.91”, Conallen, Inc.,Marzo 1999http://www.conallen.org/technologyCorner/webextension/WebExtension091.htm

[5] D. B. Lange, "An Object-Oriented Design Approach for DevelopingHypermedia Information Systems", Research Report RT0112 , IBM Research,Tokyo Research Laboratory, Japón, 1995.

[6] D. Cowan and C. Lucena. Abstract Data Views: An Interface SpecificationConcept to Enhance Design for Reuse. IEEE Transactions on SoftwareEngineering. Vol. 21, No. 3, Marzo 1995.

[7] Escalona M. J. y Koch N. “Ingeniería de Requisitos en Aplicaciones para laWeb: Un estudio Comparativo”, 2002www.pst.informatik.uni-muenchen.de/personen/kochn/ideas03-escalona-koch.pdf

[8] Fuentes Quiroz Iván, “Desarrollo de aplicaciones para la construcción de sitiosinteractivos en Internet para el comercio electrónico”, Departamento de Ingenieríaen Sistemas Computacionales, Universidad de las Américas, Puebla. 2001http://www.pue.udlap.mx/~tesis/lis/fuentes_q_i/capitulo2.pdf

[9] García De Mateos Juan Jimeno, Herrera González Patricia, Pérez Luján Mª

Carmen. “Metodologías de desarrollo de aplicaciones Web”, 2003/2004http://alarcos.inf-cr.uclm.es/doc/aplicabbdd/DASBD-UWE.pdf

[10] García Molina Jesús J.1, Moreira Ana2, Rossi Gustavo3. “Presentación UML:el lenguaje estándar para el modelado de software”, 1Depto. de Informática ySistemas, Universidad de Murcia; 2Depto. de Informática, Facultad de Ciencias yTecnología, Universidad de Nova de Lisboa (Portugal); Facultad de Informática,Universidad Nacional de La Plata (Argentina), Marzo-Abril 2004http://www.ati.es/novatica/2004/168/168-4.pdf

[11] Grupo de Ingeniería del Software. “Introducción a las aplicaciones Web”,

Departamento de Lenguaje y Sistemas Informáticos. Universidad de Sevilla,Octubre 2004



51

[12] Guerrero Luis A. “Modelando Aplicaciones Web con UML”, Departamentode Ciencias de la Computación, Universidad de Chile, Mayo 2001http://www.dcc.uchile.cl/~luguerre/cc61j/recursos/web-app.ppt

[13] Gutiérrez José A., Hilera José R., Martínez Javier, Martínez José M.

“Orientación a Objetos en la Documentación Hipermedia”, Departamento deCiencias de la Computación, Universidad de Alcalá de Henares, 1998http://www.ati.es/gt/LATIGOO/OOp96/Ponen6/atio6p06.html

[14] Hennicker Rolf, Koch Nora, Kraus Andreas. “The Authoring Process of theUML-based Web Engineering Approach”, 2000

[15] J. Nanard y M. Nanard. “Hypertext Design Environments and HypertextDesign.”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 Conferenceon Systems Science. Sprague R. 1998

[17] lycos.com. UML, Marzo 2005http://usuarios.lycos.es/oopere/uml.htm

[18] Mateu Carles. “Desarrollo de aplicaciones Web”, Universidad Oberta deCatalunya, 1ra. Edición marzo 2004http://www.uoc.edu/masters/softwarelibre/esp/materials/Desarrollo_web.pdf

[19] Mercerat Bárbara, Silva Darío Andrés. “Construyendo aplicaciones Web conuna metodología de diseño orientada a objetos”, 2002http://www.unab.edu.co/editorialunab/revistas/rcc/pdfs/r22_art5_c.pdf

[20] Popkin Software and Systems. ”Modelado de Sistemas com UML”, 2002http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-uml.pdf

[21] Pressman Roger S., Adaptado por: Darle Ince “Ingeniería del Software”. Unenfoque practico 5ª. Edición. Mc Graw Hill, 2002

[22] V. Balasubramanian. “State of the Art Review on Hypermedia Issues andApplications.” Reporte Técnico, Universidad de Rutgers, Marzo 1994. (Disponiblevía Web: http://www.isg.sfu.ca/duchier/misc/hypertext_review/index.html)

[23] Vidal Aragon Miguel Ángel. “Diseño de un prototipo de servicios Web para lacontratación de un seguro y del transporte del café”, Laboratorio Nacional deInformática Avanzada, A.C., Marzo 2003http://www.lania.mx/biblioteca/rtecnicos/Lania-RT-2003-07/LANIA-RT-2003-07-MAVA.pdf.

[24] Vilain, P., Schwabe, D., Sieckenius, C. A diagrammatic Tool for Representing

User Interaction in UML. Lecture Notes in Computer Science. Proc. UML’2000.York, England.



52

[25] Yourdon E. Modern Structured Analysis. Prentice-Hall, 1989

Otros sitios de interés:

Aplicaciones Webhttp://www.eside.deusto.es/grupos/gedi/recursos/apuntes/WebTema0.pdf

Modeling Web Application Architectures with UMLhttp://www.uml.org.cn/UMLApplication/pdf/webapps.pdf

Modelado de aplicaciones Web con UMLhttp://usuario.cicese.mx/~jburci/Docs/art6.htm

Historia de Internethttp://csc.azc.uam.mx/internet/manuales/historia.html

Una historia de Internethttp://www.galeon.com/periodismo-digital/hismontesi.htm

Documents

Tes810 Uml