Está en la página 1de 52

I

Prefacio

1. Introducción a la Web

1.1 Historia de la Web

INDICE

1.2 Historia de las aplicaciones Web

1.3 ¿Qué es una aplicación Web?

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

2. UML

2.1 Introducción a UML

2.2 Áreas de trabajo en UML

2.3 Proceso Unificado (Unified Process, UP)

2.4 Descripción de los diagramas de UML

1

4

5

6

8

9

9

10

3. Metodologías de desarrollo de aplicaciones Web

3.1 Introducción al desarrollo de aplicaciones Web

3.2 UWE (Ingeniería Web basada en UML)

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

3.4 Metodologías Basadas en Hipermedia y Orientadas a Objetos

3.4.1 ¿Qué es Multimedia?

3.4.2 ¿Qué es la Hipermedia?

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

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

3.4.5 W2000

3.4.6 EORM (Metodología de Relaciones de Objetos Mejorada)

3.5 Conclusión

17

18

19

19

20

21

22

23

23

24

4. Metodología WAE para el desarrollo de las aplicaciones Web para UML

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

4.2 Modelado

WAE (Extensión de Aplicaciones Web para UML) 4.2 Modelado 4.2.1 Páginas 4.2.2 Servidor Scripting 4.2.3 Cliente

4.2.1 Páginas

4.2.2 Servidor Scripting

4.2.3 Cliente Scripting

4.2.4 Estereotipos de Páginas

4.3 Componentes

4.3.1 Forms (Formularios)

4.3.2 Framesets

5. Prototipo de una Tienda Virtual

5.1 Descripción de la aplicación 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

25

29

29

29

30

30

33

33

34

36

36

40

48

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 los desarrolladores, 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 Estados Unidos. DARPA inicio un programa de investigación de técnicas y tecnologías para unir diversas redes de conmutación de paquetes, permitiendo así a las computadoras conectadas 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 (Department

of Energy) con la ESNET. En Europa, la mayoría de países disponían 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 sólo por TCP e IP), algunas de las cuales eran ya de código 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 número 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 demás redes de comunicación existentes (Compuserver, FidoNet/BBS, etc.). El punto de inflexión vino marcado por la aparición de implementaciones de TCP/IP gratuitas así como por la popularidad y abaratamiento de los medios de acceso cada vez más rápidos. El efecto de todos estos cambios fue como una “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 se conectaban 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 del mundo. Por eso las empresas, instituciones, administraciones y demás están migrando rá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 ligero

descanso experimentado en el ritmo de crecimiento, Internet está destinado a convertirse

en una suerte de servicios universal de comunicaciones, permitiendo una comunicación universal.

La WWW (World Wide Web) [18], se ha convertido, junto con el correo electrónico en el 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 red de 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 de este punto, el crecimiento es espectacular.

En 1993 fue el lanzamiento de Mosaic, un navegador para X-Windows que con el tiempo 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 fue

constante, convirtiéndose hacia finales de los noventas en el servicio insignia de Internet

y dando lugar al crecimiento imparable de los servicios en línea 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 implantación simple y sencilla de un sistema de comunicaciones que nos permite enviar cualquier tipo de ficheros de una forma fácil, 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 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 la

WWW. Se trata de un protocolo simple, orientado a conexión y sin estado. La razón de que esté orientado a conexión 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 contraposición a los protocolos de datagrama o no orientados a conexión

que 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ón alguna entre ellas, hasta el punto de que para transferir un página Web tenemos que enviar código HTML del texto, así como las imágenes que la componen, pues en la especificación inicial de HTTP, la 1.0, se abrían y usaban tantas conexiones como componentes tenía la página, transfiriéndose por cada conexión un componente (el texto

de la página o cada una de las imágenes).

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 tráfico entre cliente y servidor, 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 cliente establece una conexión TCP hacia el servidor, hacia el puerto HTTP (o el indicado en la dirección de la conexión), envía un comando HTTP de petición de un recurso y por la misma conexión el servidor responde con los datos solicitados y con algunas cabeceras informativas (Ver figura 1.1).

y con algunas cabeceras informativas (Ver figura 1.1). Figura 1.1 Arquitectura Cliente/Servidor El término

Figura 1.1 Arquitectura Cliente/Servidor

El término Cliente/Servidor alude a un procesamiento colaborativo de datos entre dos o má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 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 interactúan con el usuario usualmente en forma gráfica, frecuentemente se comunican 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 de sincronización 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 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 una aplicación 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 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 XML validable de HTML, proporcionándonos 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 colección de páginas estáticas, documentos, etc., que podían consultarse o descargarse. El siguiente paso en su evolución fue la inclusión de un método para confeccionar páginas dinámicas que permitiesen que lo mostrado 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 CGI siguen siendo muy utilizados, puesto que la mayoría de los servidores Web los soportan debido a su sencillez. Además, nos proporcionan total libertad a la hora de escoger el lenguaje de programación para desarrollarlos.

El esquema de funcionamiento de los CGI tenía un punto débil: cada vez que recibíamos una petición, el servidor Web lanzaba un proceso que ejecutaba el programa CGI. Como, por otro lado, la mayoría de los CGI estaba escrito en algún lenguaje interpretado (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 un lado se diseñan sistemas de ejecución de módulos más integrados con el servidor, que evitan que éste tenga que instanciar y ejecutar multitud de programas. La otra vía consiste 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 de manera 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 tiene inconvenientes 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 una nueva forma de trabajo, la cual esta orientada al trabajo del diseñador Web, quien no necesariamente conocer de lenguajes de programación. Este nuevo enfoque consiste en insertar 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 mas econó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 para el desarrollo de aplicaciones Web, representa un modelo de computación distribuida para Internet basado en XML (eXtensible Markup Language). Bajo este concepto ya no solo se trata la comunicación usuario-aplicación, sino que de manera adicional se maneja 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 como una caja negra, la cual encierra un proceso y que cumple una función claramente definida, 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 en el 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 a una robusta y entera aplicación. Ahora ya no es raro entender por una aplicación Web a cientos de usuarios simultáneos, distribuidos alrededor del mundo, todos conectados a la vez si se requiere. Este término varía de acuerdo a las personas, algunos creen que una aplicación Web es cualquier página que use java, otros consideran cualquier sistema que use un servidor Web. Aquí, una aplicación Web, será un servidor Web en el cual los usuarios introducen datos que afectan la condición del negocio. La diferencia entre una aplicación Web y un sitio Web radica en su uso. Una aplicación Web implementa la lógica del negocio, y usa cambios de estados del negocio.

Así, las aplicaciones Web son sistemas de información donde una gran cantidad de datos 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 sus necesidades. [9]

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

6

6 Figura 1.2 Arquitectura de Sitio Web dinámico La arquitectura básica de una aplicación Web [3,

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 del

cliente que son interpretados por el browser con los cuales el usuario interactúa. A veces

el usuario ingresa información en los campos de los formularios de la página y somete

estos datos al procesamiento del servidor.

página y somete estos datos al procesamiento del servidor. Figura 1.3 Arquitectura bási ca de las

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 dentro de tres categorías: páginas con código (scripts, ejecutable del lado del servidor), páginas compiladas (carga y ejecuta un componente binario) y un híbrido entre los dos. Esta ultima categoría representa páginas con código, que una vez que son solicitadas son compiladas y usadas en lo sucesivo con esta misma compilación cuentas veces se requiera.

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 e implementación que inevitablemente influyen en todo el proceso de desarrollo, afectando la división de tareas. Los problemas involucrados, como el diseño del modelo del dominio y la construcción de la interfaz de usuario, tiene requerimientos disjuntos que deben ser tratados por separado.

El alcance de la aplicación y el tipo de usuario a los que estará dirigida son consideraciones tan importantes como las tecnologías elegidas para realizar la implementación. Así como las tecnologías pueden limitar la funcionalidad de la aplicació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 particulares de 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 de diseño, así como disponer de una documentación detallada y exacta ante futuras modificaciones.

8

2.1 Introducción a UML

2. 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 buen número de métodos de desarrollo de software OO. En julio de 1993, Jacobson criticó en lo que él denominaba guerra de métodos y planteó la necesidad de llegar a una notación estándar de modelado, para evitar la confusión reinante y favorecer el uso de los mé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. El Lenguaje Unificado de Modelado (UML) es el resultado de esa colaboración y de las aportaciones de las principales empresas de software (Ver la figura 2.1).

las principales empresas de software (Ver la figura 2.1). Figura 2.1 Evolución de UML UML fue

Figura 2.1 Evolución 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 estándar de factor para visualizar, especificar y documentar los modelos que se crean durante la aplicación de un proceso de software. UML ha ejercitado un gran impacto en la comunidad del software, 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 entornos de desarrollo más 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 más precisos y más 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 estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores só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 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 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 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 generación de código por parte de herramientas exige una definición formal de UML, que se consigue mediante 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 en Rational, la empresa de sus creadores que fue adquirida por IBM a finales del 2002. En los últimos años 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 más extendido ha sido el RUP (Rational Unified Process), definido por Rational (Ver la figura 2.2).

10

10 Características del RUP: Figura 2.2 RUP • Iterativo. Refinamiento sucesivo • Controlado. Gestión de requisitos

Características del RUP:

Figura 2.2 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

• Configurable • Fomento al control de calidad Figura 2.3 Fases en el Proceso Unificado 2.4

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 hace un sistema desde el punto de vista de un observador externo, enfatizando el qué más que 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 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)

.

de preparar su café y el pan tostado (Ver la figura 2.4) . Figura 2.4 Diagrama

Figura 2.4 Diagrama de Casos de Uso Nivel 1

En los Casos de Uso, los Actores son papeles que determinadas personas u objetos desempeñan. Se representan mediante un “símbolo 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 lí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 si tomamos por separado “Preparar pan” (Ver la figura 2.5) y “Preparar café” (Ver la figura 2.6), podemos bajar un nivel de descripción y llegar a los siguientes Casos de

Uso.

de descri pción y llegar a los siguientes Casos de Uso. Figura 2.5 Diagrama Casos de

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é.”

fresa y se lo come, posiblemente mojándolo en un café.” Figura 2.6 Diagrama Casos de Uso

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 una separació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 meramente gráfico. De esta manera, combinando Casos de Uso y explicación textual, se puede obtener 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 con UML. Los Casos de Uso se emplean también en la preparación 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 interacción 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 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).

dentro de la secuenci a de mensajes (Ver la figura 2.7). Figura 2.7 Diagrama de Secuencia

Figura 2.7 Diagrama de Secuencia

Las líneas verticales o “líneas 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 línea de la vida.

Los rectángulos verticales son barras de activación y representan la duración de la ejecución del mensaje. El mensaje “Encender”, posiblemente implementado mediante la introducción del enchufe en una toma de pared, tiene una duración escasa y similar a la de “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ás interviene la emisión de un aviso cuando el pan está lo suficientemente caliente, a fin de evitar 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 “[]” expresan condición y si están precedidos de un asterisco indican interacción mientras se cumpla la 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. El mensaje asíncrono ocurre en el tiempo de manera independiente a otros mensajes. Los mensajes síncronos 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 colaboración [1]: son otro tipo de diagramas de interacción, que contienen la misma información que los de secuencia, sólo 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 colaboración tiene un número de secuencia. El primer nivel de la secuencia es 1, y los mensajes que son enviados durante la misma llamada a un método se numeran 1.1, 1.2 y así sucesivamente para tantos niveles como sea necesario.

así su cesivamente para tantos niveles como sea necesario. Figura 2.8 Diagrama de Colaboración Diagramas de

Figura 2.8 Diagrama de Colaboración

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 condición. Las transiciones son las líneas que unen los diferentes estados. En ellas se representa la condición que provoca el cambio, seguida de la acción oportuna separada por “/”. En un estado 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 la transició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 que depende la transición (entre corchetes).

Los estados inicial, a partir del que se “entra” en la máquina de estados, y final, que indica que la máquina 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 asíncronas o concurrentes.

una actividad involucra sub-actividades asíncronas o concurrentes. Figura 2.9 Máquina de Es tados, estados simples

Figura 2.9 Máquina de Estados, estados simples

14

Diagramas de actividades [1]: son básicamente diagramas de flujo adornados, que guardan mucha similitud con los diagramas de estados. Mientras que los diagramas de estados centran su atención 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 función del resultado de una condición expresada entre corchetes.

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

se pue den bifurcarse en dos o más actividades paralelas. Figura 2.10 Diagrama de Actividades Diagramas

Figura 2.10 Diagrama de Actividades

Diagramas de clases [1]: muestran un resumen del sistema en términos de sus clases y las relaciones entre ellas. Son diagramas estáticos que muestran qué es lo que interactú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 tienda de venta por catálogo. La clase principal es “Pedido”, asociada a un cliente, una forma de pago y un conjunto de artículos.

15

15 Figura 2.11 Diagrama de Clases Diagramas de objetos [1]: son análogos a los de clases,

Figura 2.11 Diagrama de Clases

Diagramas de objetos [1]: son análogos a los de clases, con la particularidad de que en lugar 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 de componentes vienen a ser los análogos físicos a los diagramas de clases. Muestran como está organizado un conjunto de componentes y las dependencias que existen entre ellos.

organizado un conjunto de compone ntes y las dependencias que existen entre ellos. Figura 2.12 Diagrama

Figura 2.12 Diagrama de componentes

16

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

modelar la configuración hardware del sistem a, mostrando qué nodos lo componen. Figura 2.13 Diagrama de

Figura 2.13 Diagrama de despliegue.

17

3. METODOLOGÍAS DE DESARROLLO DE APLICACIONES WEB

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 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 técnica estandarizada y estructurada que ofrezca un marco de desarrollo que garantice la calidad del resultado. Existe en cambio un conjunto de técnicas, cuyo uso proponen diferentes metodologías para el desarrollo de aplicaciones Web. Se debe tener en cuenta que la selección de las técnicas y el éxito de los resultados que se obtengan dependen en gran medida tanto del equipo de análisis y desarrollo como de los propios clientes o usuarios que en ella participen.

Es necesario tener estándares que regulen la creación de aplicaciones Web. Esto permite

la comunicación 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 características particulares de las aplicaciones Web.

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

La primera generación: (primera mitad de los 90’s). Sienta las bases de la Ingeniería Web al incluir conceptos como constructores de navegación, o promover la separación entre 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 e incluye 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, se enfatiza 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 implican que un usuario regrese o no al sitio; pues en el comercio electrónico, el usuario primero

se 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 los aspectos de usabilidad de una interfaz utilizada por un sistema e identificar problemas específicos; siendo una parte importante del proceso total del diseño de la interfaz de usuario, 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 de características para el desarrollo en Web, tanto así que ha surgido una nueva rama de la ingenierí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 el 2000. Esta metodología utiliza un paradigma orientado a objetos, y está orientada al usuario. Está basada en los estándares UML y UP (Proceso Unificado), cubre todo el ciclo 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 diagrama de casos de uso.

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

3. Diseño navegacional. Se obtienen el modelo de espacio de navegación y modelo de estructura de navegación, que muestra cómo navegar a través del espacio de navegació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 interfaz de usuario que se presentan mediante diagramas de interacción UML.

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

por paquetes relacionados mediante dependencias en UML. Figura 3.1 Modelo por paquetes Los aspectos principales de

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.

19

3. La especificación de restricciones, la metodología recomienda el uso de restricciones escritas en el Lenguaje de Restricciones de Objetos (OCL) para aumentar 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 la semántica del modelo de elementos específicos, el mecanismo de extensión permite incluir nuevos atributos, diferente semántica y restricciones adicionales.

El conjunto de extensión 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 extensión de UML es la habilidad de asignar iconos diferentes a las clases estereotipadas. El problema de una página 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 sería definir los estereotipos [4] (Ver la figura 3.2); método del servidor y método del cliente. En un objeto de la página un método 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 métodos de un objeto de la página, sin embargo todavía es un poco confuso. Una complicación extensa se levanta después cuando se hacen asociaciones a otros componentes en el modelo. No está claro que algunas de estas relaciones sólo son válidas en el contexto de los métodos y atributos del servidor o en los del cliente.

los métodos y atributos del servidor o en los del cliente. Figura 3.2 Estereotipos de la

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 un sistema 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 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 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 de comunicación más participativo, ya que combina información de diversos medios en una única corriente de conocimiento, aumentando el impacto que se produciría en los usuarios 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 puramente textual, 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, el hipertexto 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 usuario similar al de un reproductor de vídeo 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 presentación, como suele hacerse en muchos reproductores de discos compactos. Esta facilidad tan sólo permite al usuario que, indicando el momento exacto en que debería aparecer un contenido, se pueda llevar a cabo un rápido movimiento hasta alcanzar dicho punto. A diferencia de los enlaces hipertextuales, estos saltos no dan lugar a ningún tipo de estructura concreta en la 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 aquella información poco o nada estructurada que no puede ajustarse a los rígidos esquemas de las 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 de documentación de textos tradicionales que poseen una marcada organización.

Esta tecnología, que se caracteriza por sus ergonómicos 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 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ásico de nodo y liga.

21

Un sistema hipermedia esta hecho de nodos (conceptos) y ligas (relaciones). Los nodos están 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 también 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 básicos de un sistema hipermedia como sigue:

1. Una interfaz de usuario gráfica con navegadores y diagramas generales para ayudar a los usuarios a navegar a través de una gran cantidad de información dispersa, 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 grado sobre los procesos de ingeniería de software. Por ejemplo, diseñar el modelo de datos conceptual 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 la consistencia de los documentos hipermedia y proveen líneas de guía. Sin embargo, para los procesos de ingeniería de software, no se requiere tomar en cuenta aspectos estéticos y cognoscitivos, los cuales son dos aspectos importantes del desarrollo hipermedia. Esto implica que las propuestas de ingeniería de software tradicional no son completamente adecuadas para el diseño de sistemas hipermedia. Nanard y Nanard [15] sugiere que las aplicaciones hipermedia pueden ser mejor desarrolladas no siguiendo los pasos secuénciales de las metodologías formales tan correctamente.

3.4.3 SOHDM (Metodología de Diseño 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 definición de requisitos parte de la realización 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 comunicación. 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 gráficamente mediante los denominados SACs (Scenario Activity Chart). Cada escenario describe el proceso de interacción 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 continúa reagrupando estas clases para conseguir un modelo 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 conceptual

2. Diseño navegacional

3. Diseño de interfaces abstractas

4. Implementación

3. Diseño de interfaces abstractas 4. Implementación Diseño conceptual: durante esta actividad se c onstruye un

Diseño 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 ejecución, se podría usar un modelo de datos semántica estructural (como el modelo E/R). De este modo, en los casos 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 y subsistemas. Las clases son descritas como en los modelos orientados a objetos tradicionales. 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ón similar a UML y tarjetas de clases y relaciones similares a las tarjetas CRC (Clase Responsabilidad 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ño navegacional 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 el diseño de aplicaciones. Un modelo navegacional es construido como una vista sobre un diseño conceptual, admitiendo la construcción de modelos diferentes de acuerdo con los diferentes perfiles de usuarios. Cada modelo navegacional provee una vista subjetiva del diseñ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 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 métodos cuando se navega en 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 a correr la aplicación.

Al llegar a esta fase, el primer paso que debe realizar el diseñador es definir los ítems de información que son parte del dominio del problema. Debe identificar también, cómo son 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 un entorno 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ño Hipermedia). 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 de requisitos funcionales y análisis de requisitos navegacionales. La especificación 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 navegación 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 navegación de cada actor. La representación gráfica es 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 Sistema de Información Hipermedial (Hiperdocumento) comprendería una primera fase de Análisis Orientada a Objetos del sistema, sin considerar los aspectos hipermediales del mismo, obteniendo un Modelo de Objetos con la misma notación utilizada en OMT, que refleje la estructura de la información (mediante clases de objetos con atributos y relaciones entre las clases) y el comportamiento del sistema (a través de los métodos asociados 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 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 información (modelo abstracto hipermedial compuesto de nodos y enlaces) 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 se especifican las posibles operaciones asociadas a cada enlace de un hiperdocumento, que serán de tipo crear, eliminar, atravesar, siguiente, previo etc., así como sus posibles atributos (fecha de creación del enlace, estilo de presentación en pantalla, restricciones de acceso, etc.).

El desarrollo del Sistema concluiría con una última fase de Construcción, durante la que se 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 de múltiples formas de relaciones entre nodos) y la reutilización, por la existencia de una librería de clases de enlaces que pueden ser reutilizados en diferentes proyectos de desarrollo hipermedial.

Para automatizar la aplicación de la metodología EORM, su autor ha desarrollado, en los laboratorios de investigación de IBM, una herramienta denominada ODMTool que, junto a un generador comercial de Interfaces Gráficas de Usuario denominado ONTOS Studio 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 un repositorio de objetos que permite compartir la información de los esquemas entre las herramientas (ODMTool, ONTOS Studio) y las aplicaciones hipermediales desarrolladas.

3.5 Conclusión

La inclusión de metodologías para el desarrollo de aplicaciones Web son de vital importancia para obtener un buen producto en éste tipo de aplicaciones. Haciendo una comparación determinamos que la metodología WAE es una de las más completas, esto es 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, diagrama de estado), sino que la extensión gráfica de Jim Conallen es muy entendible con los diferentes estereotipos que se utilizan para realizar aplicaciones Web.

25

4. METODOLOGÍA WAE PARA EL DESARROLLO DE LAS APLICACIONES 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 para diseñar aplicaciones Web los cuales se describen a continuación:

Estereotipos [4]

Nombre

Página del servidor

Meta-modelo

Clase

de clase

Descripción

Una página del servidor representa una página Web que tiene scripts que son ejecutadas por el servidor. Estos scripts actúan recíprocamente con recursos en el servidor (bancos de datos, lógica 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 página (accesible por todas las funciones en la página).

Icono

Icono

Restricciones

Las páginas del servidor pueden tener sólo relaciones con objetos en el servidor.

Valores

Artefacto de Scripting - O el lenguaje o artefacto que deben ser uso para ejecutar o interpretar esta página (JavaScript, VBScript, Perl, etc.)

etiquetados

Nombre

Página del cliente

Meta-modelo

Clase

de clase

Descripción

Un caso de una página del cliente es una estructura HTML de la página Web. Como cualquier página HTML es una mezcla de datos, presentación y lógica igual. Las páginas del 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

Icono

Restricciones

Ninguna

Valores

TitleTag – El título de la página 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.

etiquetados

Nombre

Formulario (Form)

Meta-modelo

Clase

de clase

Descripción

Una clase estereotipada como un «form» es una colección de campos de entrada que son parte de una página 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 actúa recíprocamente con el formulario sería la propiedad de la página que contiene al formulario.

Icono

Icono

Restricciones

Ninguna

Valores

Método - el método suministra datos a la acción URL, cualquiera GET o POST.

etiquetados

27

Nombre

Frame Set

Meta-modelo

Clase

de clase

Descripción

Un juego de frames es un contenedor de múltiples páginas Web. La vista de los rectángulos son áreas divididas en rectángulos más pequeños de frames. Cada frame puede ser asociado mediante un solo nombre «target» aunque no necesariamente. Los contenidos de un frame pueden estar en una página Web o en otro juego de frames. Un esteriotipado de la clase de Frame se mapea directamente 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 son activados por browsers que no devuelve frames.

Icono

Icono

Restricciones

Ninguna

Valores

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.

etiquetados

Nombre

Target

Meta-modelo

Clase

de clase

Descripción

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

28

Icono

Icono

Restricciones

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

Valores

Ninguno

etiquetados

Nombre

JavaScript

Meta-modelo

Clase

de clase

Descripción

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 páginas del cliente.

Icono

Icono

Restricción

Ninguna

Valores

Ninguno

etiquetados

Link: un link es un indicador de una página del cliente a otra «Página». En un diagrama de 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, con el 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» que acepta 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 el cliente y páginas del servidor. Las páginas del servidor sólo existen en el servidor. Ellos son acostumbrados a construir páginas del cliente.

El «build» la asociación identifica qué página del servidor es responsable para la creación de una página del cliente. Ésta es una relación direccional, desde que la página del 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ágina del 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ágina Web. Puede dirigirse los dos al cliente y páginas del servidor. Si la relación origina de un «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 es completamente estructural, desde la invocación real de un funcionamiento del redireccionamiento debe hacerse programáticamente en el código de la página originado.

Si la relación se origina de un «página del cliente» entonces esto indica que la página del destino será pedida automáticamente por el browser, sin la entrada del usuario. Un valor de retraso de tiempo puede ponerse que específica un retraso (en segundos) antes de la segunda página 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 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 Web en 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 de servidor 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 pueden contener al usuario que define variables, sub-rutinas y funciones. Algunos artefactos del scripting 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 de este 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 ejecuta un script, sin embargo, no tiene acceso directo a los recursos del servidor. Típicamente

scripts 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 el servidor, así como de lado del cliente puede representarse en el modelo como dos clases separadas, aunque su implementación esté en el mismo archivo (o componente). En esta situació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ágina del lado del script; subrutinas y funciones. Una página del servidor puede tener relación

a otros componentes que existen en el servidor.

La representación de las páginas del cliente son semejantes en el diagrama de clases estereotipadas: «client page» («página del cliente»). Los atributos de página del cliente son los alcances de variables de la página y funciones que se ejecutan en el browser del cliente. Las páginas del cliente tienen métodos 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 página 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 (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 tiene acceso 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 arrastrado en 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):

una página del cliente. Por ej emplo (Ver la figura 4.1): Figura 4.1 Las páginas del

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 procesamiento a 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):

redirects>>. Por ejemplo (Ver la figura 4.2): Figura 4.2 La Página del servidor es la que

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 del servidor 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 es la página Web. Un componente en un diagrama de implementación (vista del componente en Rational Rose) representa un archivo actual que es una demanda por el servidor Web, y qué comprende una página del servidor o página del cliente por lo menos. La figura 4.3, muestra conceptualmente esta relación.

La figura 4.3, muestra c onceptualmente esta relación. Figura 4.3 Unos componentes de página Web comprenden

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

Una relación adicional que puede ser de importancia en el diseño de aplicación Web es el 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áginas del cliente desde que finalmente es el componente que es pedido por el browser del cliente.

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

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

y otras páginas (servidor o c liente). Ver la figura 4.4: Figura 4.4 Página cliente vincul
y otras páginas (servidor o c liente). Ver la figura 4.4: Figura 4.4 Página cliente vincul
y otras páginas (servidor o c liente). Ver la figura 4.4: Figura 4.4 Página cliente vincul

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, sin embargo, un bueno diseño debe modelar todos links relevantes, para la función de la aplicació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:

del link fu era de la asociación, Ver la figura 4.5: Figura 4.5 Uniéndose con parámetros

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 Web como 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 como ejecutarse en la máquina del servidor o en la máquina del cliente. Los estereotipos «server component» (componente del servidor) y «client component» (componente del cliente) 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 el contexto de la página del cliente. También es posible tener formularios múltiples en una sola página, cada targeting en una página de acción 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 métodos en una página del cliente tienen acceso a todos los atributos de los formularios contenidos dentro de una página. La relación apropiada entre una página del cliente y un formulario es 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 los atributos del formulario que se someten cuando la asociación se comprende durante el runtime.

cua ndo la asociación se comprende durante el runtime. Figura 4.6 Los formularios hacen un submit

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 aplicaciones Web 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 que están 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 páginas Web. La implementación de un frameset está en una página HTML. Una página Web de frameset 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ño de clases estereotipar un frameset pueden tener todas las asociaciones que una página del 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 del cliente puede ser contenida por un frameset. ¡Puesto que un frameset es una especializació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 la habilidad 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ágina Web activa o frame. Desde que los targets representan un elemento muy diferente de un frameset, y considerando las páginas Web pueden también referenciar targets que están 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 página 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 páginas Web contenidas en un frame se llaman targets. El estereotipo <<targeted link>> 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.

frame distinto del que contiene la página que tiene el link. Ver la figura 4.7. Figura

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 una mejor ventaja competitiva.

Negocio a Cliente [8]: el cliente puede comparar con la venta al detalle de manera electrónica. Esta categoría ha tenido gran aceptación 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 función de vender bienes y servicios, a través del Web, por lo cual está disponible las 24 horas al día, con un alcance global con la habilidad de relacionar y proporcionar información al cliente así como órdenes de compra.

La Tienda Virtual en su naturaleza se muestra como un servicio dado a través de una entidad 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 la unidad administrativa y elemental de los demás modelos de negocios del comercio electró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 en línea (marketing on-line) son innumerables, desde la generación de estadísticas de compra y venta, realización de análisis de comportamiento de mercado, análisis del cliente, de sus hábitos de consumo, así como la retroalimentación de los clientes y su autosuficiencia monetaria a través de publicidad externa la hace una excelente opción de desarrollo 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 los siguientes 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.

37

6. Si no esta inscrito se da de alta.

7. Realiza el pago

Casos de Uso del Usuario:

se da de alta. 7. Realiza el pago Casos de Uso del Usuario: Figura 5.1 Caso

Figura 5.1 Caso de Uso del Usuario de la Tienda Virtual

38

Diagrama de Secuencia de Usuario:

38 Diagrama de Secuencia de Usuario: Figura 5.2 Diagrama de Secuencia de l Usuario de la

Figura 5.2 Diagrama de Secuencia del Usuario de la Tienda Virtual

39

Diagrama de Colaboración del Usuario:

39 Diagrama de Colaboración del Usuario: Figura 5.3 Diagrama de Colaboración del Usuario de la Tienda

Figura 5.3 Diagrama de Colaboración del Usuario de la Tienda Virtual

40

Diagrama de los estereotipos del Usuario:

40 Diagrama de los estereotipos del Usuario: Figura 5.4 Diagrama de estereotipos del Usuario. 5.3 Modelando

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 categorías y productos como lo describen los siguientes puntos:

1. Registra Categorías y sus productos

2. Elimina Categorías y sus productos

3. Modifica Categorías y sus productos

41

Diagrama de Caso de Usos del Administrador:

41 Diagrama de Caso de Usos del Administrador: Figura 5.5 Caso de Uso del Admini strador

Figura 5.5 Caso de Uso del Administrador de la Tienda Virtual

Diagrama de Secuencia del Administrador:

la Tienda Virtual Diagrama de Secuencia del Administrador: Figura 5.6 Diagrama de Secuencia del Ad ministrador

Figura 5.6 Diagrama de Secuencia del Administrador de la Tienda Virtual

42

Diagrama de Colaboración del Administrador:

42 Diagrama de Colaboración del Administrador: Figura 5.7 Diagrama de Colaboración del Administrador de la Tienda

Figura 5.7 Diagrama de Colaboración del Administrador de la Tienda Virtual

Diagrama de los estereotipos del Administrador:

la Tienda Virtual Diagrama de los estereotipos del Administrador: Figura 5.8 Diagrama de 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 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 categorías que existen en la tienda virtual, las cuales también la podemos ver en parte central en la cual tiene el siguiente 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 puede compra dando click en “Agregar Artículo”.

se puede compra dando click en “Agregar Artículo”. Figura 5.9 Página principal Al seleccionar alguna de

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 productos

y

seleccionar la cantidad que se desee de ese artículo y dar click en “Agregar Artículo”

y

enviarlos al carrito de compras.

44

44 Figura 5.10 Página donde se vi sualizan los productos. Cuando se envían los productos al

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 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 algún producto ya no se desea comprar existe la posibilidad de eliminar el producto y se reduce 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”.

quiere comp rar los productos da r click en “Caja”. Figura 5.11 Página del carrito de

Figura 5.11 Página del carrito de compras

Después de haber dado click en caja debemos confirmar la entrada para confirmar la compra 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 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 opción para darse de alta para las dos opciones debe dar click en “Registrar”.

para las dos opciones debe dar click en “Registrar”. Figura 5.12 Confirmación de datos La figura

Figura 5.12 Confirmación 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 algún error en el llenado del formulario podrá ir a la siguiente página.

algún error en el lle nado del formulario podrá ir a la siguiente página. Figura 5.13

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 la compra.

revisado po r el cliente para dar por finalizada la compra. Figura 5.14 Finalización de al

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.

correctamente, de no ser así no se le dará acceso para modificar la tienda virtual. Figura

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)

la operación que deseamos realizar (insertar, modificar o eliminar) Figura 5.16 Mantenimiento de la tienda virtual

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 para realizar 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 la claridad 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 necesario aplicar metodologías, 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 metodologí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 diferentes usuarios que intervienen en el prototipo y como interactúan; esto es primordial porque no 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 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 interactúa 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 colaboración) 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 conexión que se debe realizar con los bancos, la cual quedaría de la siguiente forma:

con los bancos, la cu al quedaría de la siguiente forma: Figura 6.1 Pago de la

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 número de particularidades que demandan ciertas adaptaciones de UML con la finalidad de modelar la arquitectura.

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