You are on page 1of 52

I

INDICE


Prefacio

1. Introduccin a la Web
1.1 Historia de la Web 1
1.2 Historia de las aplicaciones Web 4
1.3 Qu es una aplicacin Web? 5
1.4 Por qu usar metodologas en el desarrollo de aplicaciones Web? 6

2. UML
2.1 Introduccin a UML 8
2.2 reas de trabajo en UML 9
2.3 Proceso Unificado (Unified Process, UP) 9
2.4 Descripcin de los diagramas de UML 10

3. Metodologas de desarrollo de aplicaciones Web
3.1 Introduccin al desarrollo de aplicaciones Web 17
3.2 UWE (Ingeniera Web basada en UML) 18
3.3 WAE (Extensin de Aplicaciones Web para UML) 19
3.4 Metodologas Basadas en Hipermedia y Orientadas a Objetos
3.4.1 Qu es Multimedia? 19
3.4.2 Qu es la Hipermedia? 20
3.4.3 SOHDM (Metodologa de Diseo Hipermedia Orientado a
Objetos y basada en escenarios) 21
3.4.4 OOHDM (Mtodo de Diseo Hipermedia Orientado a Objetos) 22
3.4.5 W2000 23
3.4.6 EORM (Metodologa de Relaciones de Objetos Mejorada) 23
3.5 Conclusin 24

4. Metodologa WAE para el desarrollo de las aplicaciones Web para UML
4.1 WAE (Extensin de Aplicaciones Web para UML) 25
4.2 Modelado 29
4.2.1 Pginas 29
4.2.2 Servidor Scripting 29
4.2.3 Cliente Scripting 30
4.2.4 Estereotipos de Pginas 30
4.3 Componentes 33
4.3.1 Forms (Formularios) 33
4.3.2 Framesets 34

5. Prototipo de una Tienda Virtual
5.1 Descripcin de la aplicacin Web (Tienda Virtual) a modelar en UML 36
5.2 Modelando la parte del usuario de la Tienda Virtual 36
5.3 Modelando la parte del administrador de la Tienda Virtual 40

6. Conclusiones y perspectivas 48

7. Bibliografa 50
II
PREFACIO

El objetivo de esta tesis es investigar la manera en que UML puede ser aplicado al
desarrollo de aplicaciones Web, y aportar una metodologa para el desarrollo de estas
aplicaciones.

El lenguaje de modelado unificado (UML) es un estndar industrial para describir
diseos. UML no es una metodologa, sino un lenguaje. Se basa en las anteriores
especificaciones de BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada
proyecto en un nmero de diagramas que representan las diferentes vistas del proyecto.
Estos diagramas juntos son los que representan la arquitectura del proyecto.

Con UML nos debemos olvidar del protagonismo excesivo que se le da al diagrama de
clases, este representa una parte importante del sistema, pero solo representa una vista
esttica, es decir, muestra al sistema parado. Sabemos su estructura pero no sabemos
que sucede a sus diferentes partes cuando el sistema empieza a funcionar. UML
introduce nuevos diagramas que representan una visin dinmica del sistema. Es decir,
gracias al diseo de la parte dinmica del sistema podemos darnos cuenta en la fase de
diseo de problemas de la estructura al propagar errores o de las partes que necesitan ser
sincronizadas, as como del estado de cada una de las instancias en cada momento. El
diagrama de clases continua siendo muy importante, pero se debe tener en cuenta que su
representacin es limitada, y que ayuda a disear un sistema robusto con partes
reutilizables, pero no a solucionar problemas de propagacin de mensajes ni de
sincronizacin o recuperacin ante estados de errores. En resumen, un sistema debe
estar bien diseado, pero tambin debe funcionar bien.

UML tambin intenta solucionar el problema de propiedad de cdigo que se da con los
desarrolladores, al implementar un lenguaje de modelado comn para todo los
desarrollos se crea una documentacin tambin comn, que cualquier desarrollador con
conocimientos de UML ser capaz de entender, independientemente del lenguaje
utilizado para el desarrollo.

UML es ahora un estndar, no existe otra especificacin de diseo orientado a objetos,
ya que es el resultado de las tres opciones existentes en el mercado. Su utilizacin es
independiente del lenguaje de programacin y de las caractersticas de los proyectos, ya
que UML ha sido diseado para modelar cualquier tipo de proyectos, tanto informticos
como de arquitectura, o de cualquier otra rea.

UML permite la modificacin de todos sus miembros mediante estereotipos y
restricciones. Un estereotipo nos permite indicar especificaciones del lenguaje al que se
refiere el diagrama de UML. Una restriccin identifica un comportamiento forzado de
una clase o relacin, es decir, mediante la restriccin estamos forzando el
comportamiento que debe tener el objeto al que se le aplica.

A continuacin se realiza un pequeo resumen por captulo de esta tesina:

En el Captulo 1 se presenta la historia de Internet y cuales eran el tipo de tecnologas
que se utilizaban para el desarrollo de las aplicaciones Web; adems la definicin de lo
que es una aplicacin Web y la arquitectura de ste tipo de aplicaciones. Se presenta
porque es necesaria la utilizacin de una metodologa para las aplicaciones Web.
III
En el Captulo 2 presenta el surgimiento de UML, su evolucin, reas de trabajo y un
marco para la definicin de software basado en esta notacin. Adems de la descripcin
de los diagramas que conforman a UML.

En el Captulo 3 se abordan las metodologas que pueden ser utilizadas para el
desarrollo de aplicaciones Web.

En el Captulo 4 se describe la metodologa WAE de una manera extensa y porque sta
metodologa es la ms completa para la realizacin de aplicaciones Web.

En el Captulo 5 se presenta el prototipo realizado con la metodologa WAE.

Finalmente en el Captulo 6 se presentan las conclusiones de este trabajo.

1
1. INTRODUCCIN A LA WEB

1.1 Historia de la Web

Internet [18], la red de redes, nace a mediados de la dcada de los setentas, bajo los
auspicios de DARPA, la Agencia de Proyectos Avanzados para la Defensa de Estados
Unidos. DARPA inicio un programa de investigacin de tcnicas y tecnologas para
unir diversas redes de conmutacin de paquetes, permitiendo as a las computadoras
conectadas a estas redes comunicarse entre s de forma fcil y transparente.

De estos proyectos naci un protocolo de comunicacin de datos, IP o Internet Protocol,
que permita a computadoras diversas comunicarse a travs de una red, Internet,
formada por la interconexin de diversas redes.

A mediados de los ochentas la Fundacin Nacional para la ciencia norteamericana, la
NSF, cre una red, la NSFNET, que se convirti en el backbone (el troncal) de Internet
junto con otras redes similares creadas por la NASA (NSINet) y U.S. DoE (Department
of Energy) con la ESNET. En Europa, la mayora de pases disponan de backbones
nacionales (NORDUNET, RedIRIS, SWITCH, etc.) y de una serie de actividades
paneuropeas (EARN y RARE). En esta poca aparecen los primeros proveedores de
acceso a Internet privados que ofrecen acceso pagado a Internet. A partir de esta poca,
gracias entre otras cosas a la amplia disponibilidad de implementaciones de las suite de
protocolos TCP/IP (formada por todos los protocolos de Internet y no slo por TCP e
IP), algunas de las cuales eran ya de cdigo libre, Internet empez lo que a mediados del
2002 empieza a descender ligeramente el ritmo de crecimiento.

A mediados de los noventas se inici el boom de Internet. En esa poca el nmero de
proveedores de acceso privado se dispar, permitiendo a millones de personas acceder a
Internet, que a partir de ese momento ya se empez a conocer como la Red,
desbancando a las dems redes de comunicacin existentes (Compuserver,
FidoNet/BBS, etc.). El punto de inflexin vino marcado por la aparicin de
implementaciones de TCP/IP gratuitas as como por la popularidad y abaratamiento de
los medios de acceso cada vez ms rpidos. El efecto de todos estos cambios fue como
una bola de nieve: a medida que se conectaban ms usuarios, los costos se reducan,
aparecan ms proveedores e Internet se haca ms atractiva y econmica, con lo que se
conectaban ms usuarios.

En estos momentos disponer de una direccin de correo electrnico, de acceso a la Web,
etc., ha dejado de ser una novedad para convertirse en algo normal en muchos pases del
mundo. Por eso las empresas, instituciones, administraciones y dems estn migrando
rpidamente todos sus servicios, aplicaciones, tiendas, etc., a un entorno Web que
permita a sus clientes y usuarios acceder a todo ello por Internet. A pesar del ligero
descanso experimentado en el ritmo de crecimiento, Internet est destinado a convertirse
en una suerte de servicios universal de comunicaciones, permitiendo una comunicacin
universal.

La WWW (World Wide Web) [18], se ha convertido, junto con el correo electrnico en
el principal caballo de batalla de Internet. sta ha dejado de ser una inmensa
biblioteca de pginas estticas para convertirse en un servicio que permite acceder a
2
multitud de prestaciones y funciones, as como a infinidad de servicios, programas,
tiendas, etc.

En 1989, mientras trabajaba en el CERN (Centro Europeo de Investigacin Nuclear),
Tim Berners-Lee empez a disear un sistema para hacer accesible fcilmente la
informacin del CERN. Dicho sistemas empleaba el hipertexto para estructurar una red
de enlaces entre los documentos. Una vez obtenida la aprobacin para continuar el
proyecto, naci el primer navegador Web, llamado WorldWideWeb.

En 1992 el sistema ya se haba extendido fuera del CERN. El nmero de servidores
estables haba aumentado, alcanzando la sorprendente cifra de veintisis. A partir de
este punto, el crecimiento es espectacular.

En 1993 fue el lanzamiento de Mosaic, un navegador para X-Windows que con el
tiempo se convertira en Netscape y que fue un factor clave de popularidad de la Web.
En 1994 se fund la WWW Consortium, que se convertira en el motor de desarrollo de
los estndares predominantes en la Web. A partir de ese momento, el crecimiento ya fue
constante, convirtindose hacia finales de los noventas en el servicio insignia de Internet
y dando lugar al crecimiento imparable de los servicios en lnea que estamos
experimentando actualmente.

El xito espectacular de la Web se basa en dos puntales fundamentos: el protocolo
HTTP y el lenguaje HTML. Uno permite una implantacin simple y sencilla de un
sistema de comunicaciones que nos permite enviar cualquier tipo de ficheros de una
forma fcil, simplificando el funcionamiento del servidor y permitiendo que servidores
poco potentes atiendan miles de peticiones y reduzcan los costos de despliegue. El otro
nos proporciona un mecanismo de composicin de pginas enlazadas simple y fcil,
altamente eficiente y de uso muy simple.

El protocolo HTTP (Hypertext Transfer Protocol) [11, 18] es el protocolo base de la
WWW. Se trata de un protocolo simple, orientado a conexin y sin estado. La razn de
que est orientado a conexin es que emplea para su funcionamiento un protocolo de
comunicaciones (TCP, transport control protocol) de modo conectado, un protocolo que
establece un canal de comunicaciones de extremo a extremo (entre el cliente y el
servido) por el que pasa el flujo de bytes que constituyen los datos que hay que
transferir, en contraposicin a los protocolos de datagrama o no orientados a conexin
que dividen los datos en pequeos paquetes (datagramas) y los envan, pudiendo llegar
por vas diferentes del servidor al cliente. El protocolo no mantiene estado, es decir,
cada transferencia de datos es una conexin independiente de la anterior sin relacin
alguna entre ellas, hasta el punto de que para transferir un pgina Web tenemos que
enviar cdigo HTML del texto, as como las imgenes que la componen, pues en la
especificacin inicial de HTTP, la 1.0, se abran y usaban tantas conexiones como
componentes tena la pgina, transfirindose por cada conexin un componente (el texto
de la pgina o cada una de las imgenes).

Existe una variante de HTTP llamada HTTPS (S por secure) que utiliza el protocolo de
seguridad SSL (secure socket layer) para cifrar y autenticar el trfico entre cliente y
servidor, siendo sta muy usada por los servidores Web de comercio electrnico, as
como por aquellos que contienen informacin personal o confidencial.

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


Figura 1.1 Arquitectura Cliente/Servidor

El trmino Cliente/Servidor alude a un procesamiento colaborativo de datos entre dos o
ms computadoras conectadas en una red.

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

Se denomina cliente al proceso que indica el dilogo o solicita los recursos y se
denomina servidor al proceso que responde a las solicitudes hechas por parte del cliente.
Las aplicaciones en el cliente y en el servidor se dividen de la siguiente manera: el
servidor contiene la parte que debe ser compartida por varios usuarios y el cliente
contiene solamente lo particular de cada usuario.

Los clientes interactan con el usuario usualmente en forma grfica, frecuentemente se
comunican con proceso auxiliares que se encargan de establecer conexin con el
servidor, enviar el pedido, recibir la respuesta, maneja las fallas y realiza actividades de
sincronizacin y de seguridad.

Los servidores proporcionan un servicio al cliente y devuelven los resultados, en
algunos casos existen procesos auxiliares que se encargan de recibir las solicitudes del
cliente, verificar la proteccin, activar un proceso servidor para satisfacer el pedido,
recibir su respuesta y enviarla al cliente. Una de las ms significantes ventajas de una
aplicacin Web es el despliegue.

Otro punto importante del xito de la WWW ha sido el lenguaje HTML (Hypertext
Mark-up Language). Se trata de un lenguaje de marcas que nos permite representar de
forma rica el contenido y tambin referenciar otros recurso, enlaces a tros documentos
4
(la caracterstica ms destacada de la WWW), mostrar formularios para posteriormente
procesarlos, etc.

El lenguaje HTML actualmente se encuentra en la versin 4.01 y empieza a
proporcionar funcionalidades ms avanzadas para crear pginas ms ricas en contenido.
Adems se ha definido una especificacin compatible con HTML, el XHTML
(eXtensible Hypertext Markup Language) que suele definir como una versin XML
validable de HTML, proporcionndonos un XML Schema contra el que validar el
documento para comprobar si est bien formado, etc.

1.2 Historia de las aplicaciones Web

Inicialmente la Web era simplemente una coleccin de pginas estticas, documentos,
etc., que podan consultarse o descargarse. El siguiente paso en su evolucin fue la
inclusin de un mtodo para confeccionar pginas dinmicas que permitiesen que lo
mostrado fuese dinmico (generado o calculado a partir de los datos de la peticin).
Dichos mtodos fueron conocidos como:

CGI (Common Gateway Interface). [18] Y defina un mecanismo mediante el cual
podamos pasar informacin entre el servidor HTTP y programas externos. Los CGI
siguen siendo muy utilizados, puesto que la mayora de los servidores Web los soportan
debido a su sencillez. Adems, nos proporcionan total libertad a la hora de escoger el
lenguaje de programacin para desarrollarlos.

El esquema de funcionamiento de los CGI tena un punto dbil: cada vez que
recibamos una peticin, el servidor Web lanzaba un proceso que ejecutaba el programa
CGI. Como, por otro lado, la mayora de los CGI estaba escrito en algn lenguaje
interpretado (Perl, Python, etc.) o en algn lenguaje que requera run-time environment
(Visual Basic, Java, etc.), esto implicaba una gran carga para la mquina del servidor.
Adems, si la Web tena muchos accesos al CGI, esto supona problemas graves. Por
ello se empiezan a desarrollar alternativas a los CGI para solucionar este grave
problema de rendimiento. Las soluciones vienen principalmente por dos vas. Por un
lado se disean sistemas de ejecucin de mdulos ms integrados con el servidor, que
evitan que ste tenga que instanciar y ejecutar multitud de programas. La otra va
consiste en dotar al servidor de un intrprete de algn lenguaje de programacin
(RXML, PHP, VBScript, etc.) que nos permita incluir las pginas en el cdigo de
manera que el servidor sea quien lo ejecute, reduciendo as el tiempo de respuesta.

Fast- CGI. Esta es una solucin similar al CGI mencionado anteriormente, solo que
propone la creacin de un solo proceso persistente por cada programa FastCGI en lugar
de por cada solicitud del cliente. Es una solucin viable pero tambin tiene
inconvenientes de proliferacin de procesos en el caso de peticiones concurrentes.

Pginas dinmicas en servidor. Con la aparicin de esta tecnologa se entra a una
nueva forma de trabajo, la cual esta orientada al trabajo del diseador Web, quien no
necesariamente conocer de lenguajes de programacin. Este nuevo enfoque consiste en
insertar pequeos fragmentos de lgica de programacin en la estructura HTML de la
pgina, al contrario de lo que se hacia en los CGIs, que era en el lenguaje de
programacin que utiliza sentencias de impresin para generar salidas HTML. En este
5
sentido se conocen diferentes alternativas, entre ellas podemos mencionar PHP, ASP,
JSP, entre otros.

Servlets. El Servlet podemos considerarlo como una evolucin de los CGIs desarrollada
por SUN Microsystems como parte de la tecnologa JAVA. De forma general consiste
en la ejecucin de aplicaciones Java en el motor de servlets (Servlet engine) el cual hace
parte del servidor Web, algo que lo hace ventajoso con respecto a los CGIs es que por
cada peticin de usuario no se crea un proceso sino un hilo, el cual es mucho mas
econmico para el sistema. Esta tecnologa hace parte de la arquitectura propuesta por
SUN en su plataforma J2EE (Java 2 Enterprise Edition).

Servicios Web. La arquitectura de servicios Web plantea algo ms que una tcnica para
el desarrollo de aplicaciones Web, representa un modelo de computacin distribuida
para Internet basado en XML (eXtensible Markup Language). Bajo este concepto ya no
solo se trata la comunicacin usuario-aplicacin, sino que de manera adicional se
maneja la interaccin aplicacin-aplicacin. Para aclarar un poco ms el concepto
tomemos como ejemplo una rutina de programacin, como sabemos una rutina es como
una caja negra, la cual encierra un proceso y que cumple una funcin claramente
definida, luego para construir una aplicacin llamamos dichas rutinas enviando
parmetros y recibiendo la respuesta respectiva. Un servicio Web se puede considerar
como una rutina a la cual se le envan los parmetros utilizando XML encapsulados en
el protocolo HTTP.

1.3 Qu es una aplicacin Web?

El trmino aplicacin Web [3, 23] ha ido evolucionando desde un pequeo sitio Web a
una robusta y entera aplicacin. Ahora ya no es raro entender por una aplicacin Web a
cientos de usuarios simultneos, distribuidos alrededor del mundo, todos conectados a la
vez si se requiere. Este trmino vara de acuerdo a las personas, algunos creen que una
aplicacin Web es cualquier pgina que use java, otros consideran cualquier sistema que
use un servidor Web. Aqu, una aplicacin Web, ser un servidor Web en el cual los
usuarios introducen datos que afectan la condicin del negocio. La diferencia entre una
aplicacin Web y un sitio Web radica en su uso. Una aplicacin Web implementa la
lgica del negocio, y usa cambios de estados del negocio.

As, las aplicaciones Web son sistemas de informacin donde una gran cantidad de
datos voltiles, altamente estructurados, son consultados, procesados y actualizados
mediante navegadores. [9]

El diseo de su interfaz est condicionado por las necesidades de claridad y simplicidad.
Debe tener una estructura que oriente a cada tipo de usuario en funcin de sus
necesidades. [9]

La arquitectura de una pgina Web [3, 12] (Ver figura 1.2) no es muy diferente de un
sitio Web dinmico. En muchas situaciones la dimensin de la lgica del negocio es
ejecutada detrs de un servidor Web en uno de las hileras del lado del servidor. La
eleccin del lenguaje de modelado y la notacin tpicamente es decidida por las
necesidades de este lado de la aplicacin.

6

Figura 1.2 Arquitectura de Sitio Web dinmico

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


Figura 1.3 Arquitectura bsica de las aplicaciones Web

Actualmente los servidores Web son mucho ms seguros, e incluyen caractersticas,
como la administracin de usuarios, el estado del servidor, proceso de la transaccin,
administracin remota, etc. Hoy en da los servidores Web pueden ser divididos dentro
de tres categoras: pginas con cdigo (scripts, ejecutable del lado del servidor), pginas
compiladas (carga y ejecuta un componente binario) y un hbrido entre los dos. Esta
ultima categora representa pginas con cdigo, que una vez que son solicitadas son
compiladas y usadas en lo sucesivo con esta misma compilacin cuentas veces se
requiera.

1.4 Por qu usar metodologas en el desarrollo de aplicaciones Web?

El desarrollo de aplicaciones Web [19] involucra decisiones no triviales de diseo e
implementacin que inevitablemente influyen en todo el proceso de desarrollo,
afectando la divisin de tareas. Los problemas involucrados, como el diseo del modelo
del dominio y la construccin de la interfaz de usuario, tiene requerimientos disjuntos
que deben ser tratados por separado.

El alcance de la aplicacin y el tipo de usuario a los que estar dirigida son
consideraciones tan importantes como las tecnologas elegidas para realizar la
implementacin. As como las tecnologas pueden limitar la funcionalidad de la
aplicacin, decisiones de diseo equivocadas tambin puede reducir su capacidad de
7
usabilidad. El marco [9] de desarrollo de este tipo de aplicaciones debe incluir un
proceso general que tenga en cuenta de manera explicita las caractersticas particulares
de las aplicaciones Web.

Para todo esto se han desarrollado metodologas que permiten estructurar, comunicar,
entender, simplificar y formalizar tanto el dominio del problema como las decisiones de
diseo, as como disponer de una documentacin detallada y exacta ante futuras
modificaciones.
8
2. UML

2.1 Introduccin a UML

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


Figura 2.1 Evolucin de UML

UML fue adoptado en noviembre de 1997 por OMG (Object Management Group) como
una de sus especificaciones y desde entonces se ha convertido en un estndar de factor
para visualizar, especificar y documentar los modelos que se crean durante la aplicacin
de un proceso de software. UML ha ejercitado un gran impacto en la comunidad del
software, tanto a nivel de desarrollo como de investigacin. Su xito ha sido enorme,
como lo prueban, por una parte, su utilizacin en todo el mundo para construir
aplicaciones en todos los dominios y de todos los tamaos, y por otra, que los entornos
de desarrollo ms extendidos como son los de Borland, Microsoft e IBM integran
herramientas para el modelado con UML. Otras dos especificaciones de OMG
relacionadas con UML son el lenguaje OCL (Object Constraint Language) y XMI
(XML Metadata Interchange). OCL es un lenguaje que se utiliza para escribir
expresiones sobre modelos, de modo que extiende la potencia expresiva de UML y
permite crear modelos ms precisos y ms completos; XMI es un formato para
intercambio de modelos basado en XML (eXtensible Markup Language).
9
El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas
estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de
lo que estos diagramas y smbolos significan. Mientras que ha habido muchas
notaciones y mtodos usados para el diseo orientado a objetos, ahora los modeladores
slo tienen que aprender una nica notacin.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software,
sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas
en los cuales modelar sistemas [20].

Diagramas de Casos de Uso para modelar los procesos business.
Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
Diagramas de Colaboracin para modelar interacciones entre objetos.
Diagramas de Estado para modelar el comportamiento de los objetos en el
sistema.
Diagramas de Actividad para modelar el comportamiento de los Casos de Uso,
objetos u operaciones.
Diagramas de Clases para modelar la estructura esttica de las clases en el
sistema.
Diagramas de Objetos para modelar la estructura esttica de los objetos en el
sistema.
Diagramas de Componentes para modelar componentes.
Diagramas de Implementacin para modelar la distribucin del sistema.

2.2 reas de trabajo en UML [10]

Los principales objetivos en el diseo de UML fueron stos: obtener un lenguaje simple
pero suficientemente expresivo, que permitiera modelar aplicaciones en cualquier
dominio, obtener un lenguaje legible; puesto que sera un lenguaje utilizado por las
personas; y permitir la generacin automtica de cdigo.

Para combinar la simplicidad con la aplicabilidad a cualquier dominio, UML incorpora
un conjunto de mecanismos de extensibilidad que permiten definir perfiles que lo
adaptan a un dominio concreto (aplicaciones Web, CORBA (Common Object Request
Broker Architecture), modelado de negocio, EJB (Enterprise Java Bean)). La legibilidad
se obtiene mediante diagramas visuales que presentan los modelos. La generacin de
cdigo por parte de herramientas exige una definicin formal de UML, que se consigue
mediante un metamodelo expresado en un metalenguaje denominado MOF (Meta-
Object Facility).

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

Es una metodologa para definir procesos de software basados en UML definido en
Rational, la empresa de sus creadores que fue adquirida por IBM a finales del 2002. En
los ltimos aos se ha definido numerosos procesos que se ajustan e los principios del
UP: procesos dirigidos por casos de uso, iterativos e incrementales, y centrados en la
arquitectura. El proceso ms extendido ha sido el RUP (Rational Unified Process),
definido por Rational (Ver la figura 2.2).
10

Figura 2.2 RUP

Caractersticas del RUP:

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



Figura 2.3 Fases en el Proceso Unificado

2.4 Descripcin de los diagramas de UML.

Diagrama de Casos de Uso [1]: los diagramas de Casos de Uso describen lo que hace
un sistema desde el punto de vista de un observador externo, enfatizando el qu ms
que el cmo. Plantean escenarios, es decir, lo que pasa cuando alguien interacta con el
11
sistema, proporcionando un resumen para una tarea u objetivo. El siguiente Caso de Uso
describe como Carlos va a desayunar (este es su objetivo), para lo que se plantea el
escenario de preparar su caf y el pan tostado (Ver la figura 2.4)
.


Figura 2.4 Diagrama de Casos de Uso Nivel 1

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


Figura 2.5 Diagrama Casos de Uso nivel 2 A

Carlos tuesta el pan en la tostadora, despus lo unta con mantequilla y mermelada de
fresa y se lo come, posiblemente mojndolo en un caf.


Figura 2.6 Diagrama Casos de Uso nivel 2 B

Carlos calienta leche, aade caf y azcar al gusto y se lo bebe.

Los Casos de Uso suelen venir delimitados por fronteras o lmites, que definen una
separacin entre lo que es realmente la funcionalidad del sistema y los actores que la
12
usan o colaboran en su desempeo. En las figuras, esta separacin viene representada
por medio de la caja que encapsula los valos. Los Casos de Uso son acompaados por
una explicacin textual que clarifica las posibles cadencias del lenguaje meramente
grfico. De esta manera, combinando Casos de Uso y explicacin textual, se puede
obtener escenarios no ambiguos, que resultan ideales en la captura de requisitos de
usuario, dada su sencillez de comprensin incluso por quien no est familiarizado con
UML. Los Casos de Uso se emplean tambin en la preparacin de escenarios de pruebas
con que verificar el software una vez ha sido construido.

Diagrama de Secuencia [1]: los diagramas de secuencia describen como los objetos
del sistema colaboran. Se trata de un diagrama de interaccin que detalla como las
operaciones se llevan a cabo, qu mensajes son enviados y cuando, organizado todo en
torno al tiempo. El tiempo avanza hacia abajo en el diagrama. Los objetos
involucrados en la operacin se listan de izquierda a derecha de acuerdo a su orden de
participacin dentro de la secuencia de mensajes (Ver la figura 2.7).


Figura 2.7 Diagrama de Secuencia

Las lneas verticales o lneas de la vida representan el tiempo de vida del objeto. La
vida del objeto carlos no termina en este diagrama, sin embargo la del objeto tosty
s y esto viene representado mediante el aspa al final de su lnea de la vida.

Los rectngulos verticales son barras de activacin y representan la duracin de la
ejecucin del mensaje. El mensaje Encender, posiblemente implementado mediante la
introduccin del enchufe en una toma de pared, tiene una duracin escasa y similar a la
de Apagar. No ocurre lo mismo con la llamada al mtodo tostar(), que dura desde la
pulsacin del botn de tostar hasta que el pan es retirado de la bandeja y adems
interviene la emisin de un aviso cuando el pan est lo suficientemente caliente, a fin de
evitar que se queme. Como se puede observar, la accin tostar viene condicionada por
la presencia de pan en la bandeja de la tostadora. En UML los corchetes [] expresan
condicin y si estn precedidos de un asterisco indican interaccin mientras se cumpla
la condicin.

Los mensajes que son intercambiados entre los objetos de un diagrama de secuencia
pueden ser sncronos o asncronos. Los mensajes asncronos son aquellos tal que el
13
emisor puede enviar nuevos mensajes mientras el original est siendo procesado. El
mensaje asncrono ocurre en el tiempo de manera independiente a otros mensajes. Los
mensajes sncronos son todo lo contrario, el emisor debe esperar a que termine el
tiempo de proceso del mensaje antes de que pueda emitir nuevos mensajes.

Diagramas de colaboracin [1]: son otro tipo de diagramas de interaccin, que
contienen la misma informacin que los de secuencia, slo que se centran en las
responsabilidades de cada objeto, en lugar de en el tiempo en que los mensajes son
enviados. Cada mensaje de un diagrama de colaboracin tiene un nmero de secuencia.
El primer nivel de la secuencia es 1, y los mensajes que son enviados durante la misma
llamada a un mtodo se numeran 1.1, 1.2 y as sucesivamente para tantos niveles como
sea necesario.

Figura 2.8 Diagrama de Colaboracin

Diagramas de estados [1]: muestran los posibles estados en que puede encontrarse un
objeto y las transiciones que pueden causar un cambio de estado. El estado de un objeto
depende de la actividad que est llevando a cabo o de alguna condicin. Las
transiciones son las lneas que unen los diferentes estados. En ellas se representa la
condicin que provoca el cambio, seguida de la accin oportuna separada por /. En un
estado en que el objeto esta pendiente de algn tipo de validacin que dependa de un
proceso en curso, no es necesario evento externo alguno para que se produzca la
transicin, ya que sta ocurrir cuando termine el proceso, en funcin del resultado de
ste. En estos casos es conveniente, por claridad, incluir la condicin que de la que
depende la transicin (entre corchetes).

Los estados inicial, a partir del que se entra en la mquina de estados, y final, que
indica que la mquina de estados termina, no tienen otro significado adicional, son
elementos ornamentales y se representan mediante un circulo negro y un circulo negro
resaltado respectivamente. Los estados de un diagrama de estados pueden anidarse, de
forma que los estados relacionados pueden ser agrupados en un estado compuesto. Esto
puede ser necesario cuando una actividad involucra sub-actividades asncronas o
concurrentes.

Figura 2.9 Mquina de Estados, estados simples
14

Diagramas de actividades [1]: son bsicamente diagramas de flujo adornados, que
guardan mucha similitud con los diagramas de estados. Mientras que los diagramas de
estados centran su atencin en el proceso que est llevando a cabo un objeto, los
diagramas de actividades muestran como las actividades fluyen y las dependencias entre
ellas.

Los diagramas de actividades pueden dividirse en calles que determinan qu objeto es
responsable de qu actividad. Las actividades vienen unidas por transiciones, que
pueden separarse en ramas en funcin del resultado de una condicin expresada entre
corchetes.

Cada rama muestra la condicin que debe ser satisfecha para que el flujo opte por ese
camino. Igualmente, las transiciones se pueden bifurcarse en dos o ms actividades
paralelas.


Figura 2.10 Diagrama de Actividades

Diagramas de clases [1]: muestran un resumen del sistema en trminos de sus clases y
las relaciones entre ellas. Son diagramas estticos que muestran qu es lo que
interacta, pero no cmo interacta o qu pasa cuando ocurre la interaccin.

El siguiente diagrama (Ver la figura 2.11) modela los pedidos de un cliente a una tienda
de venta por catlogo. La clase principal es Pedido, asociada a un cliente, una forma
de pago y un conjunto de artculos.

15

Figura 2.11 Diagrama de Clases

Diagramas de objetos [1]: son anlogos a los de clases, con la particularidad de que en
lugar de encontrar clases, encontramos instancias de stas. Son tiles para explicar
partes pequeas del modelo en las que hay relaciones complejas.

Diagramas de componentes [1]: son mdulos de cdigo, as que los diagramas de
componentes vienen a ser los anlogos fsicos a los diagramas de clases. Muestran
como est organizado un conjunto de componentes y las dependencias que existen entre
ellos.


Figura 2.12 Diagrama de componentes



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



Figura 2.13 Diagrama de despliegue.
17
3. METODOLOGAS DE DESARROLLO DE APLICACIONES
WEB

3.1 Introduccin al desarrollo de aplicaciones Web

El proceso de desarrollo de un sistema [7], sea o no para la Web, se enfrenta al
problema de la identificacin de requisitos o requerimientos. La definicin de las
necesidades del sistema es un proceso complejo pues en l hay que identificar los
requisitos que el sistema debe cumplir para satisfacer las necesidades de los usuarios
finales y de los clientes. Para realizar este proceso, no existe una nica tcnica
estandarizada y estructurada que ofrezca un marco de desarrollo que garantice la calidad
del resultado. Existe en cambio un conjunto de tcnicas, cuyo uso proponen diferentes
metodologas para el desarrollo de aplicaciones Web. Se debe tener en cuenta que la
seleccin de las tcnicas y el xito de los resultados que se obtengan dependen en gran
medida tanto del equipo de anlisis y desarrollo como de los propios clientes o usuarios
que en ella participen.

Es necesario tener estndares que regulen la creacin de aplicaciones Web. Esto permite
la comunicacin entre componentes y sistemas construidos por distintos desarrolladores
y ejecutados en distintas plataformas. El marco de desarrollo de este tipo de
aplicaciones debe incluir un proceso general que tenga en cuenta de manera explicita las
caractersticas particulares de las aplicaciones Web.

Las distintas metodologas se pueden dividir en tres generaciones, en base a su nivel de
sofisticacin, y en dos familias, las derivadas de modelos clsicos de datos (E/R) y las
derivadas de modelos Orientados a Objetos (OMT y UML).

La primera generacin: (primera mitad de los 90s). Sienta las bases de la Ingeniera
Web al incluir conceptos como constructores de navegacin, o promover la separacin
entre estructuras de navegacin y el contenido durante el proceso de desarrollo.

La segunda generacin: (segunda mitad de los 90s). Refina los primeros modelos e
incluye conceptos como los soportes de funcionalidad bsica, y los primeros esbozos de
proceso donde se delimitan los modelos conceptual, lgico y fsico.

La tercera generacin: (2000-2002). Profundiza en el soporte para la funcionalidad, se
enfatiza el artculo del usuario en los mtodos, y se producen avances hacia la
estandarizacin de notaciones, procesos y lenguajes textuales de especificacin.

Debido al gran auge que ha tenido en el mbito mundial el uso y navegacin por
Internet y la economa electrnica, los diseadores de sitios Web y quienes los contratan
para la construccin de sus portales, se han preocupado por las razones que implican
que un usuario regrese o no al sitio; pues en el comercio electrnico, el usuario primero
se enfrenta a la usabilidad y despus hace el pago.

La evaluacin o diagnstico de usabilidad consiste en las metodologas que miden los
aspectos de usabilidad de una interfaz utilizada por un sistema e identificar problemas
especficos; siendo una parte importante del proceso total del diseo de la interfaz de
usuario, que consiste en ciclos iterativos de disear, de prototipos y de la evaluacin.

18
No obstante la popularidad de UML, no se han contemplado la inclusin de
caractersticas para el desarrollo en Web, tanto as que ha surgido una nueva rama de la
ingeniera de software denominada Ingeniera Web [21], en la cual se trata de cubrir
los aspectos importantes de las aplicaciones enfocadas a la Web.

3.2 UWE (Ingeniera Web basada en UML)

La ingeniera Web basada en UML (UWE) fue presentada por Nora Koch [14] en el
2000. Esta metodologa utiliza un paradigma orientado a objetos, y est orientada al
usuario. Est basada en los estndares UML y UP (Proceso Unificado), cubre todo el
ciclo de vida de este tipo de aplicaciones centrando adems su atencin en aplicaciones
personalizadas.

UWE propone una extensin de UML que se divide en 4 pasos [9]:

1. Anlisis de requisitos. Su objetivo es encontrar los requisitos funcionales de la
aplicacin Web para representarlos como casos de uso. Da lugar a un diagrama
de casos de uso.
2. Diseo conceptual. Su objetivo es construir un modelo conceptual del dominio
de la aplicacin considerando los requisitos reflejados en los casos de uso. Da
como resultado un diagrama de clases de dominio.
3. Diseo navegacional. Se obtienen el modelo de espacio de navegacin y modelo
de estructura de navegacin, que muestra cmo navegar a travs del espacio de
navegacin. Se obtienen diagramas de clases que representan estos modelos.
4. Diseo de presentacin. De este paso se obtienen una serie de vistas de interfaz
de usuario que se presentan mediante diagramas de interaccin UML.

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


Figura 3.1 Modelo por paquetes

Los aspectos principales de esta metodologa son:

1. Uso de una notacin estndar, como es la notacin UML.
2. Definicin precisa del mtodo, una serie de pasos para seguir la construccin de
los modelos.
19
3. La especificacin de restricciones, la metodologa recomienda el uso de
restricciones escritas en el Lenguaje de Restricciones de Objetos (OCL) para
aumentar la precisin de los modelos.

3.3 WAE (Extensin de Aplicaciones Web para UML) [3]

UML tiene definido un mecanismo para permitir cierto dominio para extender la
semntica del modelo de elementos especficos, el mecanismo de extensin permite
incluir nuevos atributos, diferente semntica y restricciones adicionales.

El conjunto de extensin de UML propuesto por Jim Conallen esta formado por Valores
etiquetados, estereotipos y restricciones (Tagged Values, Stereotypes and Constraints).
La parte del mecanismo de la extensin de UML es la habilidad de asignar iconos
diferentes a las clases estereotipadas. El problema de una pgina Web es que tiene
diferentes scripts y variables que se ejecutan en el servidor o del lado del cliente, este
problema se puede resolver de dos formas:

El primero sera definir los estereotipos [4] (Ver la figura 3.2); mtodo del servidor y
mtodo del cliente. En un objeto de la pgina un mtodo que ejecuta en el servidor se
estereotipar como server method y las funciones que corren en el cliente client
method. Esto resuelve el problema de distinguir los atributos y mtodos de un objeto
de la pgina, sin embargo todava es un poco confuso. Una complicacin extensa se
levanta despus cuando se hacen asociaciones a otros componentes en el modelo. No
est claro que algunas de estas relaciones slo son vlidas en el contexto de los mtodos
y atributos del servidor o en los del cliente.


Figura 3.2 Estereotipos de la Metodologa WAE

3.4. Metodologas Basadas en Hipermedia y Orientadas a Objetos.

3.4.1 Qu es Multimedia?

Multimedia: tambin denominada integracin de medios digitales, consiste e un
sistema que utiliza informacin almacenada o controlada digitalmente (texto, grficos,
animacin, voz y vdeo) que se combinan en la computadora para formar una nica
presentacin. La multimedia se pude definir, como una combinacin de informaciones
de naturaleza diversa, coordinada por la computadora y con la que el usuario puede
interactuar. Se podr emplear para realzar y optimizar el flujo de informacin,
20
incrementando la eficacia de la comunicacin entre el usuario final y la computadora.
La utilizacin de medios digitales de forma interactiva permitir crear un entorno de
comunicacin ms participativo, ya que combina informacin de diversos medios en
una nica corriente de conocimiento, aumentando el impacto que se producira en los
usuarios si se emplea de manera separada, los medios digitales que se incluyen en una
computadora son Animacin, Grficos, Sonido y Vdeo.

3.4.2 Qu es la Hipermedia?

La hipermedia [13] es el resultado de combinacin de hipertexto y la multimedia.
Tradicionalmente, la idea de hipertexto se ha asociado con la documentacin puramente
textual, o en todo caso grfico, por lo que la inclusin de otros tipos de informacin
(vdeo, msica, etc.) suele recogerse con el nombre de hipermedia. Por una parte, el
hipertexto permite representar una estructura asociativa en la que nodos o conceptos
pueden enlazarse automticamente. Las aplicaciones multimedia permiten integrar
diferentes medios bajo una presentacin interactiva, para lo que pueden ofrecer dos
tipos de accesos a la informacin:

1. El mecanismo mayoritariamente utilizado, consiste en un control de usuario
similar al de un reproductor de vdeo o sonido que avanza siguiendo el eje de
coordenadas temporal.
2. En algunos casos, se permite realizar saltos a un determinado instante dentro de
una presentacin, como suele hacerse en muchos reproductores de discos
compactos. Esta facilidad tan slo permite al usuario que, indicando el momento
exacto en que debera aparecer un contenido, se pueda llevar a cabo un rpido
movimiento hasta alcanzar dicho punto. A diferencia de los enlaces
hipertextuales, estos saltos no dan lugar a ningn tipo de estructura concreta en
la que navegar a travs de la informacin.

Las ventajas de la hipermedia

En primer lugar, la hipermedia ofrece un medio adecuado para representar aquella
informacin poco o nada estructurada que no puede ajustarse a los rgidos esquemas de
las bases de datos tradicionales. Adems, permite estructurar la informacin,
jerrquicamente o no, de tal modo que tambin resulta til en sistemas de
documentacin de textos tradicionales que poseen una marcada organizacin.

Esta tecnologa, que se caracteriza por sus ergonmicos interfaces de usuario, muy
intuitivos, pues imitan el funcionamiento de la memoria humana, hace que el usuario no
tenga que realizar grandes esfuerzos para conseguir resultados rpidamente.

Estructura de los sistemas Hipermedia

Propiedades fundamentales en un sistema hipermedia hoy en da son:

1. El proceso de ligado entre dos tems, dando una elevacin al paradigma bsico
de nodo y liga.
2. La seleccin por asociacin, dando una elevacin al soporte de ligas que permite
el recorrido de una red de nodos en una manera directa.

21
Un sistema hipermedia esta hecho de nodos (conceptos) y ligas (relaciones). Los nodos
estn conectados a otros nodos por ligas. El nodo del cual una liga origina es llamado
referencia y el nodo en el cual la liga termina es llamado referente. Ellos son tambin
referidos como anclas. El contenido de un nodo es desplegado por ligas activas. Aparte
de esta arquitectura nodo-liga, los sistemas hipermedia tienen una estructura irregular.

Balasubramanian [22] lista los componentes bsicos de un sistema hipermedia como
sigue:

1. Una interfaz de usuario grfica con navegadores y diagramas generales para
ayudar a los usuarios a navegar a travs de una gran cantidad de informacin
dispersa, posiblemente interconectada, unida por ligas activas.
2. Un sistema con herramientas para crear y manejar nodos y ligas.
3. Mecanismos de recuperacin de informacin tradicional (tales como
bsquedas por palabra clave, bsqueda por autor, etc.)
4. Una ingeniera hipermedia para manejar informacin acerca de nodos y
ligas.
5. Un sistema de almacenaje el cual puede ser un sistema de archivos o una
base de conocimiento o un tradicional DBMS.

Diseando Sistemas Hipermedia

El proceso de desarrollo de un sistema hipermedia puede ser modelado a un cierto grado
sobre los procesos de ingeniera de software. Por ejemplo, disear el modelo de datos
conceptual y el modelo abstracto de navegacin puede beneficiarse directamente de las
propuestas de ingeniera de software. Las tcnicas de diseo formal perfeccionan la
consistencia de los documentos hipermedia y proveen lneas de gua. Sin embargo, para
los procesos de ingeniera de software, no se requiere tomar en cuenta aspectos estticos
y cognoscitivos, los cuales son dos aspectos importantes del desarrollo hipermedia. Esto
implica que las propuestas de ingeniera de software tradicional no son completamente
adecuadas para el diseo de sistemas hipermedia. Nanard y Nanard [15] sugiere que las
aplicaciones hipermedia pueden ser mejor desarrolladas no siguiendo los pasos
secunciales de las metodologas formales tan correctamente.

3.4.3 SOHDM (Metodologa de Diseo Hipermedia Orientado a Objetos y basada
en escenarios)

Esta propuesta [16] presenta la necesidad de disponer de un proceso que permita
capturar las necesidades del sistema. Para ello, propone el uso de escenarios. El proceso
de definicin de requisitos parte de la realizacin de un diagrama de contexto tal y
como se propone en diagrama de flujos de datos (DFD) de Yourdon [25]. En este
diagrama de contexto se identifican las entidades externas que se comunican con el
sistema, as como los eventos que provocan esa comunicacin. Las lista de eventos es
una tabla que indica en qu eventos puede participar cada entidad. Por cada evento
diferente SOHDM propone elaborar un escenario. stos son representados grficamente
mediante los denominados SACs (Scenario Activity Chart). Cada escenario describe el
proceso de interaccin entre el usuario y el sistema cuando se produce un evento
determinado especificando el flujo de actividades, los objetos involucrados y las
transacciones realizadas. SOHDM propone un proceso para conseguir a partir de estos
escenarios el modelo conceptual del sistema que es representado mediante un diagrama
22
de clases. El proceso de SOHDM contina reagrupando estas clases para conseguir un
modelo de clases navegacionales del sistema.

3.4.4 OOHDM (Mtodo de Diseo Hipermedia Orientado a Objetos)

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

1. Diseo conceptual
2. Diseo navegacional
3. Diseo de interfaces abstractas
4. Implementacin

Diseo conceptual: durante esta actividad se construye un esquema conceptual
representado por los objetos del dominio, las relaciones y colaboraciones existentes
establecidas entre ellos. En las aplicaciones hipermedia convencionales, cuyos
componentes de hipermedia no son modificados durante la ejecucin, se podra usar un
modelo de datos semntica estructural (como el modelo E/R). De este modo, en los
casos en que la informacin base pueda cambiar dinmicamente o se intente ejecutar
clculos complejos, se necesitar enriquecer el comportamiento del modelo de objetos.

En OOHDM el esquema conceptual est construido por clases, relaciones y
subsistemas. Las clases son descritas como en los modelos orientados a objetos
tradicionales. Sin embargo, los atributos pueden ser de mltiples tipos para representar
perspectivas diferentes de las mismas entidades del mundo real. Se usa una notacin
similar a UML y tarjetas de clases y relaciones similares a las tarjetas CRC (Clase
Responsabilidad Colaboracin).

El esquema de las clases consiste en un conjunto de clases conectadas por relaciones.
Los objetos son instancias de las clases. Las clases son usadas durante el diseo
navegacional para derivar nodos, y relaciones que son usadas para construir enlaces.

Diseo navegacional: en OOHDM la navegacin es considerada un paso crtico en el
diseo de aplicaciones. Un modelo navegacional es construido como una vista sobre un
diseo conceptual, admitiendo la construccin de modelos diferentes de acuerdo con los
diferentes perfiles de usuarios. Cada modelo navegacional provee una vista subjetiva del
diseo conceptual.

En OOHDM existen un conjunto de tipo predefinidos de clases navegacionales: nodos,
enlaces y estructuras de acceso. La semntica de los nodos y los enlaces son las
tradicionales aplicaciones hipermedia, y las estructuras de acceso, tales como ndices o
recorridos guiados, representan los posibles caminos de acceso a los nodos. Los nodos
son enriquecidos con un conjunto de clases especiales que permiten de un nodo
observar y presentar atributos (incluidos los links), as como mtodos cuando se navega
en un particular contexto.

Diseo de interfaz abstracta: en OOHDM se utiliza el diseo de interfaz abstracta
para describir la interfaz de usuario de aplicacin de hipermedia. El modelo de interfaz
ADVs [6] (Vista de Datos Abstracta) especifica la organizacin y comportamiento de la
23
interfaz, pero la apariencia fsica real o de los atributos, y la disposicin de las
propiedades de las ADVs. [6] en la pantalla real son hechas en fase de implementacin.

Implementacin: en esta fase, el diseador debe implementar el diseo. Hasta ahora,
todos los modelos fueron construidos en forma independiente de la plataforma de
implementacin; en esta fase es tenido en cuenta el entorno particular en el cual se va a
correr la aplicacin.

Al llegar a esta fase, el primer paso que debe realizar el diseador es definir los tems de
informacin que son parte del dominio del problema. Debe identificar tambin, cmo
son organizados los tems de acuerdo con el perfil del usuario y su tarea; decidir qu
interfaz debera ver y como debera comportarse. A fin de implementar todo en un
entorno Web, el diseador debe decidir adems que informacin debe ser almacenada.

3.4.5 W2000 [2]

Supone una propuesta que ampla la notacin UML con conceptos para modelar
elementos de multimedia heredados de la propuesta HDM (Mtodo de Diseo
Hipermedia). El proceso de desarrollo de W2000 se divide en tres etapas:

1. Anlisis de requisitos.
2. Diseo de hipermedia.
3. Diseo funcional.

La especificacin de requisitos en W2000 se divide en dos subactividades: anlisis de
requisitos funcionales y anlisis de requisitos navegacionales. La especificacin de
requisitos comienza haciendo un estudio de los diferentes roles de usuario que van a
interactuar con el sistema. Cada actor potencialmente distinto tendr su modelo de
requisitos de navegacin y de requisitos funcionales.

El modelo de requisitos funcionales es representado como un modelo de casos de uso
tal y como se propone en UML. En l se representa la funcionalidad principal asociada a
cada rol y las interacciones que se producen entre el sistema y cada rol.

El segundo modelo consiste en otro diagrama de casos de uso pero que no representa
funcionalidad sino posibilidades de navegacin de cada actor. La representacin grfica
es realizada con una extensin de UML.

3.4.6 EORM (Metodologa de Relaciones de Objetos Mejorada) [13]

En esta metodologa, propuesta por D. Lange [5], el proceso de desarrollo de un Sistema
de Informacin Hipermedial (Hiperdocumento) comprendera una primera fase de
Anlisis Orientada a Objetos del sistema, sin considerar los aspectos hipermediales del
mismo, obteniendo un Modelo de Objetos con la misma notacin utilizada en OMT, que
refleje la estructura de la informacin (mediante clases de objetos con atributos y
relaciones entre las clases) y el comportamiento del sistema (a travs de los mtodos
asociados a las clases de objetos).

La idea fundamental de esta metodologa es considerar una segunda fase, de Diseo,
durante la cual se proceda a modificar el modelo de objetos obtenido durante el anlisis
24
aadiendo la semntica apropiada a las relaciones entre las de objetos para convertirlas
en enlaces hipermedia, obteniendo finalmente un modelo enriquecido, que su autor
denomina EORM (Enhanced Object-Relationship Model), en el que se refleje tanto la
estructura de la informacin (modelo abstracto hipermedial compuesto de nodos y
enlaces) como las posibilidades de navegacin ofrecidas por el sistema. Sobre dicha
estructura, para lo cual existir un repositorio o librera de clases de enlaces, donde se
especifican las posibles operaciones asociadas a cada enlace de un hiperdocumento, que
sern de tipo crear, eliminar, atravesar, siguiente, previo etc., as como sus posibles
atributos (fecha de creacin del enlace, estilo de presentacin en pantalla, restricciones
de acceso, etc.).

El desarrollo del Sistema concluira con una ltima fase de Construccin, durante la que
se generara el cdigo fuente (por ejemplo en C++) correspondiente a cada clase, y se
preparara la Interfaz Grfica de Usuario.

La adopcin del enfoque orientado a objetos OMT garantiza todas las ventajas
reconocidas para esta tcnica de modelado, como la flexibilidad (posible existencia de
mltiples formas de relaciones entre nodos) y la reutilizacin, por la existencia de una
librera de clases de enlaces que pueden ser reutilizados en diferentes proyectos de
desarrollo hipermedial.

Para automatizar la aplicacin de la metodologa EORM, su autor ha desarrollado, en
los laboratorios de investigacin de IBM, una herramienta denominada ODMTool que,
junto a un generador comercial de Interfaces Grficas de Usuario denominado ONTOS
Studio y un Sistema de Gestin de Base de Datos Orientado a Objetos (SGBDOO),
permite el diseo interactivo de esquemas EORM y la generacin de cdigo fuente,
inicialmente en C++, de las clases incluidas en estos esquemas. El SGBDOO ofrece un
repositorio de objetos que permite compartir la informacin de los esquemas entre las
herramientas (ODMTool, ONTOS Studio) y las aplicaciones hipermediales
desarrolladas.

3.5 Conclusin

La inclusin de metodologas para el desarrollo de aplicaciones Web son de vital
importancia para obtener un buen producto en ste tipo de aplicaciones. Haciendo una
comparacin determinamos que la metodologa WAE es una de las ms completas, esto
es porque nos slo se utilizan los diagramas clsicos de UML (diagrama de clases,
diagrama de casos de uso, diagrama de secuencia, diagrama de colaboracin, diagrama
de estado), sino que la extensin grfica de Jim Conallen es muy entendible con los
diferentes estereotipos que se utilizan para realizar aplicaciones Web.
25
4. METODOLOGA WAE PARA EL DESARROLLO DE LAS
APLICACIONES WEB PARA UML

4.1 WAE (Extensin de Aplicaciones Web para UML)

En la explicacin de lo conceptos Web se utilizara los diagramas e iconos utilizados por
Jim Conallen. Ya que Conallen propone una extensin (o estereotipos) a UML para
disear aplicaciones Web los cuales se describen a continuacin:

Estereotipos [4]

Nombre Pgina del servidor
Meta-modelo
de clase
Clase
Descripcin Una pgina del servidor representa una pgina Web que
tiene scripts que son ejecutadas por el servidor. Estos
scripts actan recprocamente con recursos en el servidor
(bancos de datos, lgica de negocio, sistemas externos,
etc). Los funcionamientos del objeto representan las
funciones en el script, y sus atributos representan las
variables que son visibles en el alcance de la pgina
(accesible por todas las funciones en la pgina).
Icono

Restricciones Las pginas del servidor pueden tener slo relaciones con
objetos en el servidor.
Valores
etiquetados
Artefacto de Scripting - O el lenguaje o artefacto que
deben ser uso para ejecutar o interpretar esta pgina
(JavaScript, VBScript, Perl, etc.)

Nombre Pgina del cliente
Meta-modelo
de clase
Clase
Descripcin Un caso de una pgina del cliente es una estructura HTML
de la pgina Web. Como cualquier pgina HTML es una
mezcla de datos, presentacin y lgica igual. Las pginas
del cliente son dadas por browsers del cliente, y puede
26
contener scripts que son interpretadas por el browser.
Las pginas del cliente pueden estar asociaciones con otras
pginas del cliente o del servidor.
Icono

Restricciones Ninguna
Valores
etiquetados
TitleTag El ttulo de la pgina como desplegado por el
browser.
BaseTag El URL de la base para dereferencing URLs
relativo.
BodyTag El juego de atributos para la etiqueta del
<body> que pone el texto de fondo y valor por defecto.

Nombre Formulario (Form)
Meta-modelo
de clase
Clase
Descripcin Una clase estereotipada como un form es una coleccin
de campos de entrada que son parte de una pgina del
cliente. Una clase del formulario se mapea directamente a
HTML. Sus atributos representan los campos de la entrada
del formulario de HTML (input boxes, text areas, radio
buttons, check boxes, y los campos ocultos).
Un form se opera, desde que no pueden encapsularse su
funcionamiento en un formulario. Cualquier
funcionamiento que acta recprocamente con el
formulario sera la propiedad de la pgina que contiene al
formulario.
Icono

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

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

Restricciones Ninguna
Valores
etiquetados
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.

Nombre Target
Meta-modelo
de clase
Clase
Descripcin Tpicamente un target es un marco en una ventana definida
por un frameset, sin embargo un target podra ser un
completamente de un nuevo caso del browser o ventana.
Targeted link las asociaciones especifican targets como
el lugar donde una nueva pgina Web ser devuelta.
28
Icono

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

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

Restriccin Ninguna
Valores
etiquetados
Ninguno

Link: un link es un indicador de una pgina del cliente a otra Pgina. En un diagrama
de la clase un link es una asociacin entre una pgina del cliente y cualquiera otro
pgina del cliente o a una pgina del servidor.

Target link: similar a un link la asociacin, un targeted link es un link donde la
pgina asociada se da en otro target. Esta asociacin traza directamente a la HTML, con
el target especificado por el atributo del target de la etiqueta.

Submit: un submit la asociacin siempre es entre un form y una pgina del
servidor. Los Forms envan sus valores del campo al servidor a travs de pgina del
29
servidor para procesar. El servidor del Web procesa la pgina del servidor que
acepta y usa la informacin en la Form enviada.

Esta relacin indica que pgina (o pginas) puede procesar el Form, y qu Forms una
pgina del servidor tiene un poco de conocimiento.

Builds: el builds la relacin es una relacin especial que conecta el vaci entre el
cliente y pginas del servidor. Las pginas del servidor slo existen en el servidor. Ellos
son acostumbrados a construir pginas del cliente.

El build la asociacin identifica qu pgina del servidor es responsable para la
creacin de una pgina del cliente. sta es una relacin direccional, desde que la pgina
del cliente no contiene conocimiento de cmo entr en existencia.

Una pgina del servidor puede construir mltiples pginas del cliente, pero una pgina
del cliente slo puede ser construida a travs de una pgina del servidor.

Redirect: un redirect la relacin es una asociacin unidireccional con otra pgina
Web. Puede dirigirse los dos al cliente y pginas del servidor. Si la relacin origina de
un pgina del servidor entonces indica que el proceso de la demanda de la pgina
puede continuar adelante con la otra pgina. Esto siempre indica esa pgina del destino
participa en el construccin de una pgina del cliente. Esta relacin en particular no es
completamente estructural, desde la invocacin real de un funcionamiento del
redireccionamiento debe hacerse programticamente en el cdigo de la pgina
originado.

Si la relacin se origina de un pgina del cliente entonces esto indica que la pgina
del destino ser pedida automticamente por el browser, sin la entrada del usuario. Un
valor de retraso de tiempo puede ponerse que especfica un retraso (en segundos) antes
de la segunda pgina que se pide. Este uso de redireccionamiento corresponde a la
etiqueta de META y HTTP-EQUIV valor de "Refresh".

4.2 Modelado [3]

Modelar es muy importante, nos ayuda a manejar la complejidad. Un sistema puede
representarse en diferentes formas, con modelos consistentes ya que cada modelo tiene
un propsito especfico y pblico. Al modelar es importante que se capture el nivel
apropiado de abstraccin y el modelo de los artefactos.

4.2.1 Pginas [3]

El componente fundamental de una aplicacin Web es la pgina. Browsers piden
pginas (o las pginas conceptuales) de los servidores. Los servidores Web distribuyen
pginas de informacin al browsers. La composicin y organizacin de una pgina Web
en esencia esta constituida por la interfaz de usuario para la aplicacin.

4.2.2 Servidor Scripting [3]

Es importante notar que la conexin entre el cliente y el servidor slo existe durante una
peticin de la pgina. Una vez que la peticin se cumple la conexin se rompe. Toda
30
actividad en el servidor (como efectuado por el usuario) ocurre durante la peticin de la
pgina. Esto representa una distincin muy significante entre las aplicaciones de
servidor de cliente tradicionales. La lgica comercial en el servidor slo es activada por
la ejecucin de scripts dentro de las pginas pedidas por el browser.

Dependiendo en el artefacto del scripting especfico, las pginas escritas pueden
contener al usuario que define variables, sub-rutinas y funciones. Algunos artefactos del
scripting incluso permiten la definicin e interaccin de objetos.

El ltimo resultado de este servidor a procesar es:

1. Ponga al da el estado comercial del servidor.
2. Prepara un HTML estructurar pgina (interfaz del usuario) para el browser.

Una parte importante y sutil parte de la aplicacin Web es entienda y acomodando de
este paradigma de cliente y interaccin del servidor. Los objetos comerciales no siempre
son accesibles al manejar peticiones de interfaz de usuario individuales.

4.2.3 Cliente Scripting [3]

El servidor no es el nico componente en una aplicacin Web que ejecuta scripts. El
propio browser puede ejecutar cdigo escrito en una pgina. Cuando el browser ejecuta
un script, sin embargo, no tiene acceso directo a los recursos del servidor. Tpicamente
scripts que corren en el cliente aumentan la interfaz del usuario como oponerse a definir
y llevar a cabo la esencia de la lgica comercial.

4.2.4 Estereotipos de Pginas [3, 12]

Una mejor forma de modelar una pgina es separando en dos clases de estereotipos:

1. Pginas del Servidor
2. Pginas del Cliente

Cualquier pgina Web dada en una aplicacin Web que tiene funcionalidad en el
servidor, as como de lado del cliente puede representarse en el modelo como dos clases
separadas, aunque su implementacin est en el mismo archivo (o componente). En esta
situacin los mtodos del servidor de una pgina Web y el alcance de variables de la
pgina son todos contenidos en una clase en el modelo estereotipado server page
(pgina del servidor). Los mtodos de esta clase representan el servidor de la pgina
del lado del script; subrutinas y funciones. Una pgina del servidor puede tener relacin
a otros componentes que existen en el servidor.

La representacin de las pginas del cliente son semejantes en el diagrama de clases
estereotipadas: client page (pgina del cliente). Los atributos de pgina del cliente
son los alcances de variables de la pgina y funciones que se ejecutan en el browser del
cliente. Las pginas del cliente tienen mtodos que se ejecutan solamente del lado del
cliente, como por ejemplo, Java Applets y controles ActiveX, y elementos propios del
DOM (Modelo de Objeto de Documento) es una forma de representar documentos
estructurados (tales como una pgina Web HTML o un documento XML) que es
independiente de cualquier lenguaje orientado a objetos.
31

Su finalidad es definir el conjunto de objetos que pueden componer documentos HTML
(pginas Web) o XML, as como las estructuras que se definen dentro de l, sus
propiedades y sus mtodos, independientemente del lenguaje de programacin utilizado,
con el fin de evitar problemas de compatibilidad entre navegadores.

Hay una relacin fundamental entre el servidor y el cliente que son estereotipos de una
pgina Web. Una pgina del servidor finalmente establece pgina del cliente resultante.

Esta es una relacin unidireccional, desde que una pgina de HTML completada tiene
acceso pequeo a la interfaz del objeto de la pgina de servidor construida.

El estereotipo builds (construir) se aplica a las asociaciones y siempre es arrastrado
en el modelo como una asociacin unidireccional de una pgina del servidor a una
pgina del cliente. Indica qu pgina del servidor es responsable para construir una
pgina del cliente. Por ejemplo (Ver la figura 4.1):


Figura 4.1 Las pginas del servidor construyen las pginas del cliente

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

Figura 4.2 La Pgina del servidor es la que delega funcionalidad

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

Figura 4.3 Unos componentes de pgina Web comprenden servidor y pginas del
cliente

Una relacin adicional que puede ser de importancia en el diseo de aplicacin Web es
el vinculo (link). Las pginas del cliente contienen a menudo vnculos (links o anchors)
que unen a otras pginas Web. Estas otras pginas Web o pueden ser servidor o pginas
del cliente desde que finalmente es el componente que es pedido por el browser del
cliente.

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

El estereotipo: links se define para las asociaciones entre las pginas del cliente y
otras pginas (servidor o cliente). Ver la figura 4.4:


Figura 4.4 Pgina cliente vinculada a otras pginas clientes

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


Figura 4.5 Unindose con parmetros

4.3 Componentes [3]

Componentes en el sentido de interfaces disponible a los objetos en la aplicacin Web
como controles ActiveX y tambin DLLs, Java Applets o executables un estereotipo en
la extensin Web. Simplemente con componentes de las pginas que identifican como
ejecutarse en la mquina del servidor o en la mquina del cliente. Los estereotipos
server component (componente del servidor) y client component (componente del
cliente) pueden ser aplicados a las clases en el diseo del modelo para distinguir
disponibilidad. Con certeza un componente de acceso de banco de datos en el servidor
no es directamente accesible por scritps del cliente que corren en un browser.

4.3.1 Forms (Formularios) [3, 12]

Se definen estereotipos adicionales para separar y elaborar Form con el uso de HTML.
Los formularios contienen atributos adicionales que no pueden ser apropiados en el
contexto de la pgina del cliente. Tambin es posible tener formularios mltiples en una
sola pgina, cada targeting en una pgina de accin diferente. Esto puede ser planeado
creando una nueva clase estereotipada para representar un solo formulario de HTML;
form.

Una clase del formulario tiene como atributos los elementos del campo. Los mtodos en
una pgina del cliente tienen acceso a todos los atributos de los formularios contenidos
dentro de una pgina. La relacin apropiada entre una pgina del cliente y un formulario
es su contenido. Las pginas del cliente contienen formularios.

Un formulario identifica una pgina Web especfica (casi siempre con un estereotipo de
pgina de servidor) aceptar y procesar datos sometidos con el formulario. Un submits
34
es el estereotipo de la asociacin que representa la relacin entre un formulario y la
pgina Web que lo procesan, Ver la figura 4.6.

La asociacin es bi-direccional desde que la pgina del proceso tiene acceso a los
atributos del formulario que se someten cuando la asociacin se comprende durante el
runtime.


Figura 4.6 Los formularios hacen un submit a la pgina del servidor

4.3.2 Framesets [3, 12]

Una interfaz de usuario adicional (y elemento del diseo) disponible en aplicaciones
Web es el frame. Si se usa en una aplicacin, representa una habilidad de presentar
pginas Web mltiples al mismo tiempo. Tpicamente estas pginas concurrentes que
estn juntas relacionadas representan una sola interfaz de usuario.

Los frames se implementan en HTML usando un frameset. Un frameset especifica y
opcionalmente los nombres de los frames separados en los que pueden darse pginas
Web. La implementacin de un frameset est en una pgina HTML. Una pgina Web de
frameset contiene normalmente estructura y contenido informativo que slo se ve en el
browsers ms viejo. Esto nos lleva a modelar framesets como una pgina del cliente,
pero uno especializado, y de un nuevo estereotipo: "frameset". En un modelo de diseo
de clases estereotipar un frameset pueden tener todas las asociaciones que una pgina
del cliente puede tener, con la comprensin que stos son slo apropiados para
browsers ms viejos.

35
Tpicamente, los framesets contienen pginas del cliente mltiples. Cualquier pgina del
cliente puede ser contenida por un frameset. Puesto que un frameset es una
especializacin de una pgina del cliente, tambin puede contenerse en un frameset!
Actividad coordinanda entre las pginas en frames (u otras ventanas) requiere la
habilidad de referenciar pginas dentro de los frames.

El Target es el trmino usado cuando una referencias de pgina de cliente a otra pgina
Web activa o frame. Desde que los targets representan un elemento muy diferente de un
frameset, y considerando las pginas Web pueden tambin referenciar targets que estn
en otro browsers abierto, otro estereotipo de la clase se define; "target". Un target no
tiene ninguna propiedad o atributos, es meramente un recipiente referenciable para una
pgina del cliente. Una clase del frameset puede contener un target, o un target puede
existir independientemente (como en el caso de una ventana del browser separada).

Las pginas Web contenidas en un frame se llaman targets. El estereotipo <<targeted
link>> hace referencia a pginas que van a ser cargadas en un frame distinto del que
contiene la pgina que tiene el link. Ver la figura 4.7.




Figura 4.7 Usando framesets y targets.
36
5. PROTOTIPO DE UNA TIENDA VIRTUAL

5.1 Descripcin de la aplicacin Web (Tienda Virtual) a modelar en UML

Dentro de los modelos de negocios que existen en el comercio electrnico se presenta la
Tienda Virtual dentro del paradigma de Negocios a Clientes (b2c) [8].

El comercio electrnico es una metodologa moderna en el proceso de comercializacin,
ayudada por la tecnologa de punta como una nueva maniobra para el desarrollo de una
mejor ventaja competitiva.

Negocio a Cliente [8]: el cliente puede comparar con la venta al detalle de manera
electrnica. Esta categora ha tenido gran aceptacin y se ha ampliado sobre manera
gracias al WWW, ya que existen diversos centros comerciales por todo Internet
ofreciendo toda clase de bienes de consumo.

Lugar Comercial el cual funge la funcin de vender bienes y servicios, a travs del
Web, por lo cual est disponible las 24 horas al da, con un alcance global con la
habilidad de relacionar y proporcionar informacin al cliente as como rdenes de
compra.

La Tienda Virtual en su naturaleza se muestra como un servicio dado a travs de una
entidad comercial o empresarial en los modelos del comercio electrnico es donde se
presentan procesos definidos y capaces de ser automatizados. Y por si fuera poco es la
unidad administrativa y elemental de los dems modelos de negocios del comercio
electrnico [8].

Una Tienda Virtual va ms all de ser un almacn electrnico de los productos de sta,
representa una estrategia de negocio, pues las aplicaciones para una mercadotecnia en
lnea (marketing on-line) son innumerables, desde la generacin de estadsticas de
compra y venta, realizacin de anlisis de comportamiento de mercado, anlisis del
cliente, de sus hbitos de consumo, as como la retroalimentacin de los clientes y su
autosuficiencia monetaria a travs de publicidad externa la hace una excelente opcin de
desarrollo y sobre todo si se busca disear la aplicacin que la gente, administre y
presente.

Por lo anterior podemos definir una Tienda Virtual como el modelo de negocios de
comercio electrnico que consta de aplicaciones de administracin de servicios y
procesos de mercadotecnia en lnea con la funcin de vender bienes y servicios.

5.2 Modelando la parte del usuario de la Tienda Virtual

El usuario es la persona que va a interactuar con la tienda virtual como lo describen los
siguientes pasos:

1. Ve las categoras 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 introduccin de sus datos.
37
6. Si no esta inscrito se da de alta.
7. Realiza el pago



Casos de Uso del Usuario:

Figura 5.1 Caso de Uso del Usuario de la Tienda Virtual
38
Diagrama de Secuencia de Usuario:


Figura 5.2 Diagrama de Secuencia del Usuario de la Tienda Virtual

39
Diagrama de Colaboracin del Usuario:

Figura 5.3 Diagrama de Colaboracin del Usuario de la Tienda Virtual

40
Diagrama de los estereotipos del Usuario:



Figura 5.4 Diagrama de estereotipos del Usuario.

5.3 Modelando la parte del administrador de la Tienda Virtual

El administrador es otro usuario, el cual se encargara de dar de alta, eliminar y
modificar las categoras y productos como lo describen los siguientes puntos:

1. Registra Categoras y sus productos
2. Elimina Categoras y sus productos
3. Modifica Categoras y sus productos










41
Diagrama de Caso de Usos del Administrador:

Figura 5.5 Caso de Uso del Administrador de la Tienda Virtual

Diagrama de Secuencia del Administrador:


Figura 5.6 Diagrama de Secuencia del Administrador de la Tienda Virtual
42
Diagrama de Colaboracin del Administrador:

Figura 5.7 Diagrama de Colaboracin del Administrador de la Tienda Virtual

Diagrama de los estereotipos del Administrador:



Figura 5.8 Diagrama de estereotipos del Administrador.
43
La figura 5.9 seria la presentacin de la tienda virtual, en la cual podemos identificar en
la parte azul, las siguientes ligas:

1. Inicio
2. Administrador
3. Confirmar la entrada

En la parte superior de color negro podemos visualizar las categoras que existen en la
tienda virtual, las cuales tambin la podemos ver en parte central en la cual tiene el
siguiente mensaje Seleccin la categora que desees:

En la parte derecha de la pantalla podemos ver un producto el cual si se desea se puede
compra dando click en Agregar Artculo.


Figura 5.9 Pgina principal

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

Figura 5.10 Pgina donde se visualizan los productos.

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


Figura 5.11 Pgina del carrito de compras

Despus de haber dado click en caja debemos confirmar la entrada para confirmar la
compra de los productos, al seleccionar la primera opcin es porque ya estamos
registrados como usuarios en la tienda virtual, y debemos de ingresar los datos claves
que nos pide los cuales son el E-mail y el Password (Ver figura 5.12). Sin el usuario no
45
se ha registrado debe de seleccionar la segunda opcin para darse de alta para las dos
opciones debe dar click en Registrar.


Figura 5.12 Confirmacin de datos

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

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


Figura 5.14 Finalizacin de al compra

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


Figura 5.15 Administracin

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


Figura 5.16 Mantenimiento de la tienda virtual

48
6. CONCLUSIONES Y PERSPECTIVAS.

CONCLUSIONES

En este trabajo se hace una descripcin de cada una de las metodologas utilizadas para
realizar aplicaciones Web, haciendo un anlisis de la Extensin de Aplicaciones Web
para UML (WAE), es una de las metodologas ms completas por el hecho de la
claridad con la que cuenta sus estereotipos (clases) en el diseo de estas aplicaciones,
adems de los diagramas habituales de UML.

Es por eso que las aplicaciones Web como en los sistemas de informacin es necesario
aplicar metodologas, esto es para realizar de una mejor manera y eficientemente ste
tipo de aplicaciones. Es por ello que se pretende que se conozca y se utilice la
metodologa WAE dando como resultado aplicaciones de calidad.

El prototipo de la tienda virtual est realizado con la ayuda de la metodologa WAE, en
primer lugar se defini lo que es una tienda virtual y en segundo lugar los diferentes
usuarios que intervienen en el prototipo y como interactan; esto es primordial porque
no todos los usuarios interactan de la misma forma.

La interaccin del usuario de la tienda virtual es eleccin de la categora que se
muestran en la tienda y se eligen los productos, los cuales son llevados a un carrito de
compra donde se contabiliza los productos y el costo que se debe de pagar.

La parte en la que el administrador interacta con la tienda es la parte del
mantenimiento (insertar, modificar o eliminar) de sta.

El prototipo se realizo con los diagrama que son interactivos (diagrama de casos de
usos, diagrama de secuencia y el diagrama de colaboracin) dentro de UML y el
diagrama de estereotipos de Jim Conallen, ya que como sabemos que las aplicaciones
Web tienen que ser interactivas con los diferentes usuario que consultan este tipo de
aplicaciones.

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

49
PERSPECTIVAS

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


Figura 6.1 Pago de la orden.

UML ha sido desarrollado para responder a los requerimientos del desarrollo de
aplicaciones orientadas a objetos tradicionales. Las aplicaciones Web presentan un
cierto nmero de particularidades que demandan ciertas adaptaciones de UML con la
finalidad de modelar la arquitectura.

La perspectiva de la tesis es desarrollar una metodologa para adaptar UML al
desarrollo de aplicaciones Web, con la colaboracin de metodologas ya existentes.

You might also like