UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR

Transcripción

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
INGENIERÍA
EN INFORMÁTICA
PROYECTO FIN DE CARRERA
Diseño y desarrollo de un portal de comercio electrónico
haciendo uso de las tecnologı́as de la información y
comunicación: e-ZOCO
Raúl Miguel Sabariego
Junio, 2009
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
Departamento de Tecnologı́as y Sistemas de Información
PROYECTO FIN DE CARRERA
Autor: Raúl Miguel Sabariego
Director: José Jesús Castro Sánchez
Junio, 2009.
TRIBUNAL:
Presidente:
Vocal 1:
Vocal 2:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE
Fdo.:
VOCAL 1
Fdo.:
VOCAL 2
Fdo.:
SECRETARIO
Fdo.:
Este documento se compuso con LATEX.
Resumen
El comercio electrónico está asumiendo cada vez mayor importancia en el desarrollo de
las economı́as nacionales y regionales, es por esto que desde organismos tanto públicos como
privados, se está fomentando la creación, difusión y transferencia de conocimiento y tecnologı́a en este campo al sector empresarial (ver referencias [3], [1] y [4]).
El comercio electrónico se puede definir como cualquier forma de transacción o intercambio de información con fines comerciales en la que las partes interactúan utilizando tecnologı́as de la información y comunicación (TIC) en lugar de hacerlo por intercambio o contacto
fı́sico directo [1]. En la actualidad, existen los denominados mercados virtuales que establecen una nueva forma de comerciar vı́a Internet, permitiendo el acceso interactivo a catálogos
de productos, listas de precios y folletos publicitarios y la venta directa e interactiva de productos a los clientes. Estos mercados pueden ser tan simples como catálogos en lı́nea, cuyo
único objetivo es llegar a un mayor número de personas, ya que no hay necesidad de atraer
a los clientes hasta los locales de venta, y permitir que los potenciales compradores puedan
escoger los productos en la tranquilidad de sus hogares, sin la asistencia o presión, según
sea el caso, de un vendedor. O pueden ser más complejos, permitiendo que determinadas
actividades de cualquier transacción comercial sean realizadas por agentes inteligentes.
En el World Wide Web, existen gran cantidad de portales que permiten a los usuarios o
empresas vender o comprar bienes o servicios [2][34]. Estos portales se caracterizan por la
gran cantidad de información que poseen sobre los productos en venta. Tal cantidad de información resulta inabordable, dificultando la localización de la que realmente es útil. Además
esta información muchas veces es obsoleta, ya que no existe un mecanismo que permita la
comunicación fluida y ágil entre vendedores y gestores de la base de datos del portal, lo que
hace que las informaciones sobre productos o sus precios no sea correcta o por lo menos no
coincidan las que aparecen en el portal con las que aparecen en las páginas webs propias de
los vendedores.
La temática de este proyecto se centra en la construcción de un portal de comercio electrónico que facilitará principalmente: la localización de productos mediante varias técnicas de
búsqueda (precisa, difusa, texto y categorı́as), la orientación en la especificación de las restricciones de búsqueda basándose en un algoritmo de aprendizaje automático, la gestión del
catálogo de productos ofertado, la gestión de usuarios del portal, la venta y adquisición de
productos, la valoración de los usuarios y la generación de estadı́sticas de uso del portal entre
otras.
La aplicación implementada ha sido desarrollada en el Grupo de investigación Oreto de la
Escuela Superior de Informática, Universidad de Castilla-La Mancha bajo el proyecto de investigación e-Pactos (ref. PAC06-0141) financiado por la Consejerı́a de Educación y Ciencia
de la Junta de Comunidades de Castilla-La Mancha.
La aplicación desarrollada puede ser probada en la dirección web: http://personal.oreto.infcr.uclm.es/apps/ezoco/
A mis padres, mi hermano, mi cuñada,
mi sobrino y futura sobrina.
A Patricia.
III
Agradecimientos
No ha sido nada fácil llegar hasta aquı́, pero si a alguien tengo que agradecer este logro
es sin duda alguna a mis padres Andrés y Josefa, que tanto se han esforzado para ayudarme.
Muchas gracias a los dos, sin vosotros no hubiese sido posible.
No quiero olvidarme de una persona muy especial que me ha apoyado mucho durante los
últimos meses, quizá de los más duros, gracias Patricia.
Agradecer también su colaboración al director de Proyecto Pepe Castro por sus consejos y
directrices. También a Lorenzo Manuel López-López y a Javier Albusac que me han ayudado
en algunos aspectos de la aplicación.
V
Índice general
Índice de figuras
XI
Índice de tablas
XVII
Código de interés
XVIII
1. Introducción
1.1. Estado del arte . . . . . . . . . . . . . . . . . . . . . .
1.2. Propuesta de una arquitectura multi-agente . . . . . . .
1.3. Servicios de Catálogo, Búsqueda y Recomendación . .
1.3.1. Un sistema de categorı́as jerárquico . . . . . .
1.3.2. Sistema de Búsqueda o Selección de Productos
1.3.3. Adquisición de Conocimiento del Mercado . .
1.4. Un ejemplo para mostrar el funcionamiento del agente
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
4
9
17
18
20
29
38
2. Objetivos
47
3. Metodologı́a de desarrollo
3.1. El Proceso Unificado como metodologı́a de desarrollo software
3.1.1. Dirigido por casos de uso . . . . . . . . . . . . . . . .
3.1.2. Centrado en la arquitectura . . . . . . . . . . . . . . .
3.1.3. Iterativo e incremental . . . . . . . . . . . . . . . . .
3.1.4. El ciclo de vida del Proceso Unificado . . . . . . . . .
3.1.5. Adaptación de la metodologı́a al presente Proyecto . .
3.2. Metodologı́a de desarrollo de base de datos . . . . . . . . . .
3.2.1. Fase 1. Modelado Conceptual . . . . . . . . . . . . .
3.2.2. Fase 2. Diseño lógico . . . . . . . . . . . . . . . . . .
3.2.3. Fase 3. Diseño fı́sico . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
51
51
52
52
53
54
56
57
58
59
60
.
.
.
.
.
61
62
69
70
72
72
4. Aplicación de la metodologı́a
4.1. Catálogo de requisitos del sistema . . . . . . . . . . . .
4.2. Elección de la Tecnologı́a . . . . . . . . . . . . . . . . .
4.2.1. Sistema Gestor de Base de Datos . . . . . . . . .
4.2.2. Lenguaje de programación . . . . . . . . . . . .
4.2.3. Configuración de la conexión con la base de datos
VII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
VIII
ÍNDICE GENERAL
4.2.4. Tecnologı́a web empleada . . . . . . . . . . . . . . . . . . . .
4.2.5. Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . .
4.2.6. Diseño de la interfaz . . . . . . . . . . . . . . . . . . . . . . .
4.2.7. Herramientas para la creación de los diagramas y documentación
4.3. Diseño de la base de datos . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1. Modelo Entidad Interrelación . . . . . . . . . . . . . . . . . . .
4.3.2. Modelo Relacional . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3. Modelo fı́sico . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4. Aplicación del Proceso Unificado . . . . . . . . . . . . . . . . . . . . .
4.4.1. Plan de iteraciones . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2. Resumen del Proceso Unificado aplicado al Proyecto . . . . . .
4.4.3. Relaciones entre los Modelos implementados . . . . . . . . . .
4.4.4. Arquitectura del Sistema . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75
80
81
81
82
82
88
93
100
100
114
115
117
5. Diseño de la interfaz
121
5.1. Elección de una interfaz adecuada . . . . . . . . . . . . . . . . . . . . . . . 121
5.2. Modelo navegacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6. Manual de usuario
6.1. La Zona Pública . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. La Zona Privada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3. La Zona de Administración . . . . . . . . . . . . . . . . . . . . . . . . . . .
127
127
132
135
7. Conclusiones
139
7.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
A. Diagramas de la base de datos
145
A.1. Diagrama entidad / interrelación . . . . . . . . . . . . . . . . . . . . . . . . 145
A.2. Diagrama relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
B. Diagramas del Proceso Unificado
B.1. Diagramas de casos de uso . . . .
B.1.1. Diagramas de la iteración 0
B.2. Diagramas de análisis . . . . . . .
B.3. Diagramas de secuencia . . . . . .
B.4. Diagramas de clase* . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
157
157
157
163
172
172
178
187
187
197
217
217
ÍNDICE GENERAL
C. Reuniones
C.1. Reunión del dı́a 25 de Septiembre de 2008
C.2. Reunión del dı́a 15 de Octubre de 2008 . .
C.3. Reunión del dı́a 22 de Octubre de 2008 . .
C.4. Reunión del dı́a 11 de Noviembre de 2008
C.5. Reunión del dı́a 18 de Noviembre de 2008
C.6. Reunión del dı́a 6 de Mayo de 2009 . . .
C.7. Otras reuniones . . . . . . . . . . . . . .
IX
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
239
239
240
241
242
242
243
244
D. Modelo navegacional
245
E. Organización del CD adjunto
251
Bibliografı́a
253
X
ÍNDICE GENERAL
Índice de figuras
1.1.
1.2.
1.3.
1.8.
Esquema base de datos definición de categorı́as. . . . . . . . . . . . . . . .
Esquema base de datos para almacenamiento de productos. . . . . . . . . .
Valores únicos y rangos, crisp y difusos representados como funciones trapezoidales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Espacio de referencia para la clase ci . . . . . . . . . . . . . . . . . . . . . .
La Similaridad entre el valor de una variable cualquiera que define un producto (izquierda) y el valor especificado por el usuario (derecha) puede verse como el cálculo del área del conjunto difuso entre (en color gris), en el
caso de variables continuas. . . . . . . . . . . . . . . . . . . . . . . . . . .
Dominio de definición de la variable utilidad . . . . . . . . . . . . . . . . .
Valor de la variable precio en la especificación oi y valores tomados para la misma variable por dos productos diferentes exci y eyci . Las distancias
parciales dN (exci , oi , vcji ) y dN (eyci , oi , vcji ) tendrán el mismo valor, aunque la
primera será negativa para expresar el hecho de que la valoración en la variable precio del producto exci es menor que la valoración establecida en la
especificación oi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dominio de definición de la variable dist (DDVdist ). . . . . . . . . . . . . .
31
34
3.1.
3.2.
3.3.
Ciclo de un sistema software desde el punto de vista del PUD . . . . . . . .
Fases del Proceso Unificado de Desarrollo . . . . . . . . . . . . . . . . . .
Iteraciones del Proceso Unificado de Desarrollo . . . . . . . . . . . . . . .
55
57
58
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
Flujo de trabajo de JSF . . . . . . . . . . . . . . . . . . . .
Comparativa no registros - no atributos - tiempo (s) (parte I) .
Comparativa no registros - no atributos - tiempo (s) (parte II)
Tiempos de respuesta con ı́ndices . . . . . . . . . . . . . . .
Tiempos de respuesta de la consulta optimizada . . . . . . .
Arquitectura del sistema software desarrollado . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
77
99
100
101
102
119
5.1.
5.2.
5.3.
5.4.
Aspecto de la alternativa 1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
122
123
123
124
6.1.
6.2.
Interfaz para la búsqueda de empresas . . . . . . . . . . . . . . . . . . . . 128
Empresa localizada en una búsqueda de empresas . . . . . . . . . . . . . . 128
1.4.
1.5.
1.6.
1.7.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
XI
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
21
21
26
28
29
XII
ÍNDICE DE FIGURAS
6.3.
6.4.
6.5.
6.6.
6.7.
6.8.
6.9.
6.10.
6.11.
6.12.
6.13.
6.14.
Búsqueda simplificada de productos . . . . . . . . . . . .
Opciones de visualización . . . . . . . . . . . . . . . . . .
Información básica de un producto . . . . . . . . . . . . .
Atributo asociado a una categorı́a en la búsqueda avanzada
Estudio de relaciones entre variables . . . . . . . . . . . .
Componente para pujar por un producto . . . . . . . . . .
Enlace al videotutorial . . . . . . . . . . . . . . . . . . . .
Aspecto del cuadro de opciones de la zona privada . . . . .
Interfaz de venta de productos (para un vendedor) . . . . .
Formulario de venta de productos . . . . . . . . . . . . . .
Interfaz de votación . . . . . . . . . . . . . . . . . . . . .
Opciones de administración . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
128
129
129
130
130
131
132
133
133
134
135
136
A.1.
A.2.
A.3.
A.4.
A.5.
A.6.
A.7.
A.8.
A.9.
A.10.
Vista panorámica del diagrama entidad interrelación
Sección A del diagrama entidad interrelación . . . .
Sección B del diagrama entidad interrelación . . . .
Sección C del diagrama entidad interrelación . . . .
Sección D del diagrama entidad interrelación . . . .
Vista panorámica del diagrama relacional . . . . .
Sección A del diagrama relacional . . . . . . . . .
Sección B del diagrama relacional . . . . . . . . .
Sección C del diagrama relacional . . . . . . . . .
Sección D del diagrama relacional . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
146
147
148
149
150
152
153
154
155
156
B.1.
B.2.
B.3.
B.4.
B.5.
B.6.
B.7.
B.8.
B.9.
B.10.
B.11.
B.12.
B.13.
B.14.
B.15.
B.16.
B.17.
B.18.
B.19.
B.20.
B.21.
Casos de uso del sistema de configuración de parámetros . . . . . . .
Casos de uso del sistema de registro de productos . . . . . . . . . . .
Casos de uso del sistema de búsqueda . . . . . . . . . . . . . . . . .
Casos de uso para la gestión del catálogo de productos . . . . . . . . .
Casos de uso del sistema de gestión de cuentas . . . . . . . . . . . . .
Casos de uso del sistema de identificación . . . . . . . . . . . . . . .
Casos de uso del sistema de mensajes . . . . . . . . . . . . . . . . . .
Casos de uso del sistema de gestión de productos . . . . . . . . . . .
Casos de uso del sistema de gestión de tipos de dato . . . . . . . . . .
Casos de uso del sistema de búsqueda de empresas . . . . . . . . . . .
Casos de uso para la consulta de productos . . . . . . . . . . . . . . .
Casos de uso del buscador difuso . . . . . . . . . . . . . . . . . . . .
Caso de uso generación de informe de búsqueda . . . . . . . . . . . .
Casos de uso del sistema de gestión de cuentas de usuario (ampliación)
Casos de uso del sistema de sugerencias de localización . . . . . . . .
Casos de uso carga masiva de productos . . . . . . . . . . . . . . . .
Caso de uso registro de incidencias . . . . . . . . . . . . . . . . . . .
Caso de uso envı́o de mensajes . . . . . . . . . . . . . . . . . . . . .
Casos de uso del sistema de votaciones . . . . . . . . . . . . . . . . .
Caso de uso envı́o de mensajes . . . . . . . . . . . . . . . . . . . . .
Caso de uso mantenimiento de productos . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
158
158
159
160
161
161
162
162
163
164
164
165
165
166
167
167
168
168
169
169
170
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE DE FIGURAS
B.22.
B.23.
B.24.
B.25.
B.26.
B.27.
B.28.
B.29.
B.30.
B.31.
B.32.
B.33.
B.34.
B.35.
B.36.
B.37.
B.38.
B.39.
B.40.
B.41.
B.42.
B.43.
B.44.
B.45.
B.46.
B.47.
B.48.
B.49.
B.50.
B.51.
B.52.
B.53.
B.54.
B.55.
B.56.
B.57.
B.58.
B.59.
B.60.
B.61.
B.62.
B.63.
B.64.
B.65.
B.66.
Caso de uso mantenimiento de votaciones . . . . . . . . . . . . . .
Casos de uso del sistema de votaciones . . . . . . . . . . . . . . . .
Casos de uso del sistema de votaciones . . . . . . . . . . . . . . . .
Análisis del sistema de búsqueda . . . . . . . . . . . . . . . . . . .
Análisis del sistema de configuración de parámetros . . . . . . . . .
Análisis del sistema de gestión de productos . . . . . . . . . . . . .
Análisis del sistema de gestión de cuentas . . . . . . . . . . . . . .
Análisis del sistema de gestión de identificación . . . . . . . . . . .
Análisis del sistema de registro de productos . . . . . . . . . . . . .
Análisis del sistema de gestión de mensajes . . . . . . . . . . . . .
Análisis del sistema de adquisición de productos . . . . . . . . . . .
Análisis del sistema de registro de productos . . . . . . . . . . . . .
Análisis del sistema de búsqueda de empresas . . . . . . . . . . . .
Análisis del sistema de consulta de productos . . . . . . . . . . . .
Análisis del sistema de búsqueda difusa . . . . . . . . . . . . . . .
Análisis del sistema de gestión de cuentas . . . . . . . . . . . . . .
Análisis del sistema de gestión de correos . . . . . . . . . . . . . .
Análisis del sistema de sugerencias . . . . . . . . . . . . . . . . . .
Análisis del sistema de adquisición de productos . . . . . . . . . . .
Análisis del sistema de gestión de productos (más detalles) . . . . .
Análisis del sistema de incidencias . . . . . . . . . . . . . . . . . .
Análisis del sistema de mensajes (avanzado) . . . . . . . . . . . . .
Análisis del sistema Tareas periódicas. Borrado de mensajes . . . . .
Análisis del sistema Tareas periódicas. Mantenimiento de productos
Análisis del sistema Tareas periódicas. Generación de informes . . .
Análisis del sistema Tareas periódicas. Mantenimiento de votaciones
Análisis del sistema de votaciones . . . . . . . . . . . . . . . . . .
Diagrama de secuencia: registro de productos . . . . . . . . . . . .
Diagrama de secuencia: configuración de parámetros . . . . . . . .
Diagrama de secuencia: gestión del catálogo de productos . . . . . .
Diagrama de secuencia: gestión de cuentas (A) . . . . . . . . . . . .
Diagrama de secuencia: gestión de cuentas (B) . . . . . . . . . . . .
Diagrama de secuencia: identificación . . . . . . . . . . . . . . . .
Diagrama de secuencia: sistema de mensajes . . . . . . . . . . . . .
Diagrama de secuencia: adquisición de productos . . . . . . . . . .
Diagrama de secuencia: registro de productos . . . . . . . . . . . .
Diagrama de secuencia: gestión de tipos de datos . . . . . . . . . .
Diagrama de secuencia: adquisición de productos (A) . . . . . . . .
Diagrama de secuencia: de adquisición de productos (B) . . . . . . .
Diagrama de secuencia: adquisición de productos (C) . . . . . . . .
Diagrama de secuencia: búsqueda de empresas . . . . . . . . . . . .
Diagrama de secuencia: consulta de productos . . . . . . . . . . . .
Diagrama de secuencia: búsqueda difusa . . . . . . . . . . . . . . .
Diagrama de secuencia: sistema de correos . . . . . . . . . . . . . .
Diagrama de secuencia: gestión de cuentas (A) . . . . . . . . . . . .
XIII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
170
171
171
172
173
173
174
175
175
176
176
177
178
179
179
180
181
181
182
182
183
183
184
184
185
185
186
187
188
189
190
191
192
193
194
195
196
197
198
198
199
200
201
202
203
XIV
ÍNDICE DE FIGURAS
B.67. Diagrama de secuencia: gestión de cuentas (B) . . . . . . . . . . . . . .
B.68. Diagrama de secuencia: gestión de cuentas (C) . . . . . . . . . . . . . .
B.69. Diagrama de secuencia: sugerencias de localización . . . . . . . . . . .
B.70. Diagrama de secuencia: carga masiva de productos . . . . . . . . . . .
B.71. Diagrama de secuencia: consultar caracterı́sticas de un producto . . . .
B.72. Diagrama de secuencia: registro de incidencias (A) . . . . . . . . . . .
B.73. Diagrama de secuencia: registro de incidencias (B) . . . . . . . . . . .
B.74. Diagrama de secuencia: envı́o de mensajes . . . . . . . . . . . . . . . .
B.75. Diagrama de secuencia: tareas periódicas. Borrado de mensajes . . . . .
B.76. Diagrama de secuencia: tareas periódicas. Informe de búsqueda (A) . . .
B.77. Diagrama de secuencia: tareas periódicas.Informe de búsqueda (B) . . .
B.78. Diagrama de secuencia: tareas periódicas. Mantenimiento de productos .
B.79. Diagrama de secuencia: tareas periódicas. Mantenimiento de votaciones
B.80. Diagrama de secuencia: sistema de votaciones (A) . . . . . . . . . . . .
B.81. Diagrama de secuencia: sistema de votaciones (B) . . . . . . . . . . . .
B.82. Dependencias del paquete dominio.correo . . . . . . . . . . . . . . . .
B.83. Dependencias del paquete dominio.entidades . . . . . . . . . . . . . . .
B.84. Dependencias del paquete dominio.entidades.persistentes . . . . . . . .
B.85. Dependencias del paquete dominio.gestionbusqueda.aprendizaje . . . .
B.86. Dependencias del paquete dominio.gestionbusqueda . . . . . . . . . . .
B.87. Dependencias del paquete dominio.gestioncategorias . . . . . . . . . .
B.88. Dependencias del paquete dominio.gestionconfiguracion . . . . . . . .
B.89. Dependencias del paquete dominio.gestioncuentas . . . . . . . . . . . .
B.90. Dependencias del paquete dominio.gestionincidencias . . . . . . . . . .
B.91. Dependencias del paquete dominio.gestionmensajes . . . . . . . . . . .
B.92. Dependencias del paquete dominio.gestionproductos.adquisicion . . . .
B.93. Dependencias del paquete dominio.gestionproductos . . . . . . . . . .
B.94. Dependencias del paquete dominio.gestiontipos . . . . . . . . . . . . .
B.95. Dependencias del paquete dominio.gestionvotaciones . . . . . . . . . .
B.96. Dependencias del paquete dominio.sugerencias . . . . . . . . . . . . .
B.97. Dependencias del paquete dominio.tareasperiodicas . . . . . . . . . . .
B.98. Dependencias del paquete dominio.tareasperiodicas.pdfgenerator . . . .
B.99. Dependencias del paquete persistencia.hibernate . . . . . . . . . . . . .
B.100. Dependencias del paquete persistencia.hibernate.sessionmanagement . .
B.101. Dependencias del paquete persistencia.hibernate.persistencia . . . . . .
B.102. Dependencias del paquete presentacion.beans.administracion . . . . . .
B.103. Dependencias del paquete presentacion.beans . . . . . . . . . . . . . .
B.104. Dependencias del paquete presentacion.beans.privado . . . . . . . . . .
B.105. Dependencias del paquete presentacion . . . . . . . . . . . . . . . . . .
B.106. Dependencias del paquete presentacion.phaselistener . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
204
204
205
206
207
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
230
231
232
233
233
234
235
236
237
238
238
D.1.
D.2.
D.3.
D.4.
.
.
.
.
.
.
.
.
246
247
248
249
Vista panorámica del modelo navegacional
Modelo navegacional (A) . . . . . . . . .
Modelo navegacional (B) . . . . . . . . .
Modelo navegacional (C) . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE DE FIGURAS
D.5.
XV
Modelo navegacional (D) . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
XVI
ÍNDICE DE FIGURAS
Índice de tablas
1.1. Tabla de distancias parciales entre cada producto ekci y la especificación oi
conforme a cada variable vcji ∈ Vc′i . . . . . . . . . . . . . . . . . . . . . . . .
1.4. Conjunto de reglas iniciales para el Precio. . . . . . . . . . . . . . . . . . . .
1.5. Conjunto de reglas iniciales para el Peso. . . . . . . . . . . . . . . . . . . . .
1.6. Conjunto de reglas iniciales para la Longitud. . . . . . . . . . . . . . . . . .
1.7. Conjunto de reglas generales para el Precio. . . . . . . . . . . . . . . . . . .
1.8. Conjunto de reglas generales para el Peso. . . . . . . . . . . . . . . . . . . .
1.9. Conjunto de reglas generales para la Longitud. . . . . . . . . . . . . . . . . .
1.10. Conjunto de reglas generales para el Precio. . . . . . . . . . . . . . . . . . .
1.2. Conjunto de entrenamiento con distancias parciales entre cada producto ekci y
la especificación oi conforme a cada variable vcji ∈ Vc′i . . . . . . . . . . . . .
1.3. Conjunto de entrenamiento con distancias parciales entre cada producto ekci y
la especificación oi conforme a cada variable vcji ∈ Vc′i . Continuación de la
Tabla 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
33
40
40
41
41
41
42
42
44
45
Comparativa de Tecnologı́as Web basadas en Java: JSP, Struts y JSF. . . . . . 76
Asignación de motores de MySQL a las relaciones de la aplicación (parte I). . 95
Asignación de motores de MySQL a las relaciones de la aplicación (parte II). 96
Cuadro resumen de la aplicación del Proceso Unificado al Proyecto . . . . . . 115
Trazabilidad de modelos de Proceso Unificado (I) . . . . . . . . . . . . . . . 116
Trazabilidad de modelos de Proceso Unificado (II) . . . . . . . . . . . . . . . 117
XVII
XVIII
ÍNDICE DE TABLAS
Código de interés
4.1. Aspecto del fichero de configuración de JSF (faces-config.xml) . . . . . . . .
4.2. Algunas restricciones de clave ajena de la aplicación . . . . . . . . . . . . .
4.3. Tabla adicional para controlar la restricción de clave ajena mediante disparadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4. Restricción de clave ajena mediante disparadores (al insertar) . . . . . . . . .
4.5. Restricción de clave ajena mediante disparadores (al actualizar) . . . . . . . .
4.6. Restricciones on delete cascade y on update cascade . . . . . . . . . . . . . .
XIX
78
94
95
96
97
97
XX
CÓDIGO DE INTERÉS
Capı́tulo 1
Introducción
1.1. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2. Propuesta de una arquitectura multi-agente . . . . . . . . . . . . . . . . . . . . . . .
9
1.3. Servicios de Catálogo, Búsqueda y Recomendación . . . . . . . . . . . . . . . . . . . 17
1.3.1.
Un sistema de categorı́as jerárquico . . . . . . . . . . . . . . . . . . . . . . 18
1.3.2.
Sistema de Búsqueda o Selección de Productos . . . . . . . . . . . . . . . . 20
1.3.3.
Adquisición de Conocimiento del Mercado . . . . . . . . . . . . . . . . . . 29
1.4. Un ejemplo para mostrar el funcionamiento del agente . . . . . . . . . . . . . . . . . 38
La consolidación en la última década de la Internet en general, y la World Wide Web
en particular, como tecnologı́as del dı́a a dı́a ha permitido la aparición de un nuevo entorno
competitivo en el que las empresas pueden desarrollar sus procesos de negocio [55, 58] expandiendo éstos ası́ a un nivel global como nunca antes habı́a sido posible imaginar [80].
Estas ventajas han propiciado que no sólo las grandes compañı́as ya existentes antes de la
aparición de estas tecnologı́as hayan extendido sus procesos de negocio a este entorno, sino
que además ha permitido la aparición de nuevas compañı́as cuyos modelos están basados
única y exclusivamente en estas infraestructuras tecnológicas. La alta competitividad en este
entorno, ha llevado a las compañı́as que habitan en él a desarrollar un alto nivel de sofisticación e integración tecnológicas, lo que ha provocado la aparición de una nueva infraestructura
tecnológica con el objetivo de dar soporte a este nuevo paradigma de negocio. Ésta recibe el
nombre de Comercio Electrónico (e-Commerce), el cuál puede ser definido como cualquier
proceso de negocio cuyas transacciones son llevadas a cabo de forma electrónica [17]. Los
1
2
Capı́tulo 1. Introducción
procesos y tecnologı́as desarrolladas bajo el campo del comercio electrónico han introducido
nuevas formas de llevar a cabo los procesos tradicionales de negocio.
Dentro del ámbito del comercio electrónico es posible distinguir varios paradigmas de
negocio con diferencias substanciales. Uno de los más exitosos es el llamado comercio C2C
(Consumer-to-Consumer), el cuál se caracteriza por el hecho de que las transacciones son llevadas a cabo por los propios consumidores, los cuáles negocian directamente entre ellos para
tratar de encontrar un acuerdo. La particularidad del comercio C2C es la posibilidad de que
un mismo individuo puede adoptar los roles de vendedor y comprador en diferentes transacciones. Una de las primeras aplicaciones del comercio C2C y posiblemente la que llevó a este
paradigma y a las tecnologı́as que le dan soporte a la popularidad es la subasta electrónica.
El éxito rotundo de esta aplicación se debe fundamentalmente a la posibilidad de superar las
barreras geográficas inherentes a las subastas tradicionales y proporcionar ası́ la posibilidad
de que cualquier individuo desarrolle actividades de compra/venta de bienes en cualquier momento y desde cualquier punto del mundo. Tras el éxito alcanzado por las aplicaciones del
comercio C2C, muchas compañı́as comenzaron a utilizar esta infraestructura para desarrollar
actividades de venta directa de productos, lo que llevó a la utilización de los portales de comercio C2C como portales B2C (Business-to-Consumer) o de venta directa. Prueba de ello,
según [16], el número de transacciones llevadas a cabo mediante subasta electrónica está decreciendo ligeramente, mientras que la cantidad de operaciones realizadas bajo el paradigma
de venta directa está creciendo en los últimos años.
Probablemente a causa de los orı́genes de muchos de los portales de comercio electrónico
más populares hoy en dı́a, como sitios de subasta electrónica (C2C), la inmensa mayorı́a de
ellos utiliza descripciones lexicográficas para la organización y la búsqueda de los productos
que son objeto de transacción. Esto lleva a los consumidores a la necesidad de especificar de
forma textual palabras clave o modelos especı́ficos del producto que desean comprar. Sin embargo, aunque esta aproximación parece adecuada para el ámbito de las subastas electrónicas,
donde los consumidores normalmente tratan de encontrar productos raros o exclusivos que
pueden ser fácilmente accedidos mediante descripciones textuales, parece bastante inapropiado para ser aplicado en el ámbito de la venta directa debido a los siguientes inconvenientes:
i) las búsquedas lexicográficas pueden devolver resultados irrelevantes debido al a polisemia
3
de muchas de las palabras más comúnmente utilizadas, y ii) debido a la especificación de las
caracterı́sticas de los productos mediante cadenas de texto en campos descriptivos, la utilización de tecnologı́as para la comparación y recomendación automáticas de productos resulta
extremadamente complicada.
Además, en operaciones de venta directa es donde se pone de manifiesto más claramente
la gran diferencia en el grado de incertidumbre que de forma usual se encuentra en la información manejada por compradores y vendedores. Es decir, mientras que los vendedores
normalmente conocen bien las caracterı́sticas de los productos que ponen a la venta, los compradores normalmente carecen de un conocimiento preciso de lo que pueden encontrar, lo que
les lleva a especificar naturalmente lo que quieren de forma vaga o imprecisa [76]. Además,
la falta de conocimiento acerca del estado del mercado en relación al producto que los consumidores desean encontrar normalmente les conduce a la elección de aquel producto más
popular dentro de su categorı́a, aunque posiblemente éste no sea el mejor o más adecuado
desde el punto de vista de la relación calidad / precio.
Estos problemas conducen a la propuesta en éste trabajo de un portal de comercio electrónico enfocado a operaciones de venta directa bajo el paradigma B2C en el que las caracterı́sticas
a destacar son las siguientes: i) desarrollo de un sistema jerárquico de catálogo de productos
en el que éstos son organizados y descritos de acuerdo a un conjunto de caracterı́sticas, ii) un
sistema de selección de productos que permite manejar la vaguedad e incertidumbre con la
que normalmente son especificados los requisitos del comprador, iii) un sistema de recomendación que permite la comparación y la selección de los productos que son más relevantes
de acuerdo a la especificación realizada por los compradores y iv) un sistema de orientación
que ayude al usuario a buscar productos reales según el mercado. Para ello, se ha hecho uso
de técnicas, conceptos y procedimientos del campo de la lógica difusa como herramientas de
manejo de incertidumbre, teniendo muy en cuenta la usabilidad del portal resultante (uno de
los mayores problemas en las propuestas de este tipo existentes actualmente).
Además, el portal desarrollado contará con los componentes usuales en cualquier portal
de comercio electrónico (C|B)2C:
Sistema de Gestión del Catálogo de Productos,
4
Sistema de Gestión de Usuarios,
Sistema de Gestión de Mensajes,
Sistema de Gestión de Votaciones,
Sistema de Gestión de Incidencias,
Sistema de Búsqueda lexicográfico de productos,
Sistema de Gestión de productos,
Sistema de Gestión de procesos de venta,
Sistema de Gestión de procesos de subasta,
Sistema de Gestión de información personal, y
Sistema de Generación de informes.
1.1.
Estado del arte
En la actualidad existen una gran cantidad de aplicaciones de propósito especı́fico, tanto
de código abierto (OpenXpertya) como de código privado (EDIWIN, Interges Online, NIC Ecommerce) para dar soporte a las necesidades del comercio electrónico [83]. También se han
utilizado algunos sistemas de gestión de contenidos de propósito general, tales como Joomla,
para facilitar las actividades de comercio electrónico [51].
En la red se pueden encontrar una gran cantidad de portales destinados al comercio
electrónico, entre los que se puede destacar eBay [34], Amazon [9], Ecommerce Times [78],
CD-NOW [8], 1-800-flowers [5], Buy [15], Krillion [56], Smallbusiness (yahoo) [89], Todocoleccion [79], etc. La mayorı́a de ellos permiten llevar a cabo actividades de comercio
electrónico del tipo C2C, B2C y B2B. Estos portales de comercio electrónico se pueden
clasificar como portales de propósito general y portales especializados. En los portales de
propósito general puede encontrarse cualquier tipo de producto, mientras que en los especializados se centran en la venta de un único género de producto. Últimamente ha aparecido una
1.1. Estado del arte
5
nueva tendencia, cuyo objetivo es permitir la presencia de pequeñas empresas en la web o
incluso personas individuales, abriendo su propio portal de comercio electrónico en la web.
Además de estos portales también se han encontrado metabuscadores de comercio electrónico, que lo único que hacen es ofrecer referencias a otros portales de comercio electrónico (p.e.
Shopnow [77]).
De entre todos los portales existentes en la red sólo unos cuantos gozan de popularidad
destacada. Ello es debido, no sólo al catálogo de productos que ofertan, si no también a las
facilidades que ofrecen a la hora de localizar productos dentro del portal en base a unos
criterios de búsqueda establecidos por el usuario. La mayorı́a de los buscadores de estos
portales:
Permiten realizar búsquedas por medio de la navegación en un catálogo de productos.
Los portales actuales disponen de un catálogo de productos que en la mayorı́a de los
casos se clasifican por medio de una lista de categorı́as poco detallada. Sólo en algunos
casos se usa un árbol de categorı́as para realizar tal clasificación.
Permiten realizar búsquedas textuales, mediante la especificación de palabras clave. En
muchos casos estas búsquedas conducen a productos que nada tienen que ver con lo
que desea el usuario, generalmente debido a la sinonimia de las palabras.
Permiten realizar búsquedas avanzadas. En la mayorı́a de los casos, estas búsquedas
avanzadas, se centran en una serie de filtros aplicados sobre algunas de las caracterı́sticas generales del producto que está buscando el usuario, tales como el precio.
Permiten realizar búsquedas combinadas de exploración de categorı́as y textual. Es
decir, una vez situado el usuario en una categorı́a del catálogo, la especificación de una
cadena hará que se busque dicha cadena únicamente en la categorı́a actual.
Permiten ordenar los resultados de búsqueda en base a alguna caracterı́stica general,
p.e. precio, tiempo de finalización del anuncio, etc. Es aquı́ donde radica una de las
caracterı́sticas que diferencian a unos portales de otros. Por ejemplo, en amazon los
usuarios pueden valorar los productos en los que están interesados, para posteriormente
emplear esa valoración para ordenar los resultados de búsqueda de otros usuarios.
6
Permiten buscar productos asociándolos a una localidad o ciudad en concreto (eBay,
krillion).
En la actualidad, se está comenzando a incorporar a los portales sistemas que recomienden
a los usuarios productos en base a su perfil, sus visitas previas o a especificaciones de lo que
busca.
Los sistemas de recomendación, también conocidos como sistemas de selección de productos, pueden ser clasificados de acuerdo al tipo de productos para los cuáles las recomendaciones son realizadas. Según este criterio, resultan dos categorı́as generales de sistemas: i) sistemas para la recomendación de productos de baja implicación (Low Involvement Products),
como libros, discos musicales o pelı́culas; y ii) sistemas para la recomendación de productos
de alta implicación (High Involvement Products), como electrodomésticos, cámaras de vı́deo
y fotográficas, instrumentos musicales o vehı́culos [53]. Una definición más detallada de lo
que productos de alta y baja implicación significan en la literatura de marketing puede ser
encontrada en [27].
En el caso de los LIP, el número de órdenes de compra son normalmente mayores en
comparación con el caso de los HIP. Por tanto, las recomendaciones en el caso de sistemas de
venta de LIP son ofrecidas en base al histórico de compras y búsquedas del cliente en cuestión, detalles demográficos o intereses que han sido explı́citamente especificados por él. Una
de las técnicas más ampliamente utilizada para ofrecer y recomendar productos de este tipo
es la denominada Collaborative Filtering (CF). Las técnicas basadas en CF tratan de identificar aquellos otros clientes con preferencias y gustos similares y ofrecen los productos que
éstos compraron como recomendación. El resultado son las tı́picas recomendaciones del tipo
“...aquellos clientes que compraron una guitarra eléctrica también compraron un amplificador...”. En [87, 54] puede encontrarse una descripción más detallada de diferentes métodos y
técnicas de selección de productos basadas en CF.
En el caso de los productos HIP, los sistemas de recomendación son diseñados para tomar como entrada una descripción del producto buscado, la cuál es analizada para encontrar
aquellos otros productos en la base de datos que son más similares a la descripción dada por
el cliente. Esta descripción es proporcionada normalmente como un conjunto de caracterı́sticas valoradas de acuerdo a las exigencias del cliente. Tras el análisis de esta descripción, el
1.1. Estado del arte
7
resultado de la recomendación es normalmente una lista de productos ordenados según su
similitud con la descripción proporcionada por el cliente.
El problema de selección de productos resulta más complejo a la hora de recomendar
productos de tipo HIP que de LIP. Las principales razones son que 1) los productos HIP
requieren normalmente de una descripción más detallada debido a que poseen muchas más
funcionalidades o caracterı́sticas que los productos LIP, 2) al ser productos mucho más caros,
las actividades de recomendación y soporte a la decisión resultan más necesarias y requeridas
por los clientes; y 3) son categorı́as productos que reciben muchas menos órdenes de compra
que aquellos productos de tipo LIP, por lo que llamar la atención sobre un modelo o marca en
concreto es una actividad que puede ser muy interesante para los vendedores. Por estos motivos, el resto del trabajo está enfocado a la actividad de portales de venta directa de productos
de tipo HIP. A continuación en esta sección se comentan algunos de los trabajos que han sido
más relevantes para realizar esta investigación.
Un servicio de gran importancia en sistemas de recomendación aplicados a portales de
comercio electrónico es el de organización o catálogo de productos. En [90], los autores describen una metodologı́a para la construcción de taxonomı́as dinámicas basadas en atributos
especificados por el cliente. El sistema presentado busca productos que satisfagan dicha descripción y los presenta al cliente si éstos son encontrados. En caso de no encontrar ningún
producto que cumpla con la descripción introducida, una lista de los productos más similares
a ésta es presentada al cliente. En [41], una aproximación basada en razonamiento basado en
casos (Case-Based Reasoning o CBR) y aplicada al problema de selección de productos es
descrita. De acuerdo a esta propuesta, cada producto en la base de datos es representado como un caso descrito mediante un conjunto de atributos. A su vez, los requisitos especificados
por el cliente son también capturados y representados como un caso. El análisis de productos
es entonces llevado a cabo mediante el estudio de la similitud entre el caso que describe los
requisitos del cliente y aquellos que describen los productos en la base de datos mediante
una estrategia basada en una aproximación de vecinos más cercanos. Aquellos productos con
valores de similitud superiores son presentados al cliente como recomendación.
Uno de los problemas a tratar a la hora de capturar los requisitos del cliente es el del
manejo de la vaguedad e imprecisión inherente en ellos. Además, la importancia de este pro-
8
blema se incrementa en el caso de ofrecer productos de tipo HIP por motivos obvios. Entre
las herramientas existentes para manejar vaguedad e incertidumbre, una de las más ampliamente utilizadas y validadas por la comunidad cientı́fica es la lógica difusa. A continuación
se comentan varias propuestas existentes en la literatura acerca que hacen uso de técnicas y
métodos extraı́dos de la lógica difusa para manejar la incertidumbre y vaguedad en las preferencias de búsqueda y que permiten a los clientes expresar sus requerimientos utilizando
un vocabulario cercano a ellos. En [75], los autores presentan una metodologı́a basada en
lógica difusa para el desarrollo de sistemas de recomendación. En ella se hace uso de conjuntos difusos para la representación de productos y construcción de reglas de recomendación
y justificación. En la metodologı́a propuesta, las recomendaciones ofrecidas están basadas
únicamente en las preferencias especificadas por el cliente que ha especificado la búsqueda y
hacia el cuál va dirigida la recomendación. Este tipo de métodos recibe el nombre de métodos
de reclusión (reclusive methods), debido a que las recomendaciones son construidas y ofrecidas para un sólo cliente. En [14], los autores presentan una metodologı́a construida sobre la
base de [90] para la selección eficiente de productos. La propuesta descrita en esta referencia
trata el diseño de una herramienta de soporte a la decisión que toma en cuenta varias caracterı́sticas de los productos estudiados, las analiza con respecto a los requisitos especificados
por el cliente y finalmente clasifica los productos estudiados en una taxonomı́a compuesta
de diferentes categorı́as que representan el potencial interés que pueden tener los producto
para el cliente. En todos estos trabajos, los conceptos y técnicas extraı́dos de la lógica difusa
son normalmente utilizados para la representación de las caracterı́sticas de los productos, las
cuales suelen ser imprecisas y conflictivas y no conmensurables entre ellas.
La mayorı́a de estos trabajos presentan sistemas de recomendación que tienen el objetivo
de asistir al usuario en el problema de selección de producto que tiene lugar de forma natural en los portales de comercio electrónico. Sin embargo, otra funcionalidad con un gran
potencial en este tipo de portales es la asistencia al usuario en forma de información relevante acerca del estado del mercado en relación al tipo de producto que se desea adquirir.
Es decir, información para que el cliente sepa qué es lo que puede adquirir y a qué precio y
qué combinaciones de funcionalidades y coste no son factibles. En [46], los autores proponen un algoritmo basado en aprendizaje supervisado y lógica difusa que tiene el objetivo de
1.2. Propuesta de una arquitectura multi-agente
9
inferir conocimiento a partir de la información contenida en la base de datos del propio portal
donde la búsqueda es efectuada. El conocimiento inferido es presentado al cliente en forma
de reglas difusas, lo cuál aumenta las capacidades explicativas del conocimiento inferido al
ser este comunicado en un lenguaje cercano al usuario.
La lógica difusa es ampliamente utilizada en el ámbito del comercio electrónico para manejar la incertidumbre y vaguedad con las que los clientes suelen expresar sus requisitos y
para dotar de capacidades de justificación al conocimiento inferido y a las recomendaciones
ofrecidas. Sin embargo, uno de los mayores problemas de los portales de comercio electrónico que utilizan la lógica difusa en sus servicios de búsqueda y recomendación de productos
es el gran impacto que resulta en la usabilidad del portal, la cual decrece considerablemente
debido a la gran cantidad de datos que el cliente está obligado a introducir [49]. Resaltar en
este sentido que el 75 % de los internautas abandonan el proceso de compra por lentitud o
exceso de requisitos solicitados [70]. Para solventar en parte estos problemas, en este trabajo se propone un servicio de selección, recomendación y orientación al usuario basado en
lógica difusa y aprendizaje supervisado tratando de reducir al máximo la cantidad de datos
requeridos al usuario para impactar lo menos posible en la usabilidad del portal.
Además, desde un punto de vista general, el comercio electrónico supone un problema
complejo y abierto en el que múltiples entidades cooperan con el objetivo final de negociar.
Por este motivo, en los últimos años se han comenzado a utilizar los sistemas multi-agente como soporte a los portales web de comercio electrónico en los que se permiten los procesos de
negociación [11, 42, 50, 45]. Gracias a este enfoque, el modelado de las partes que componen
el portal de comercio electrónico se realiza de manera natural mediante agentes inteligentes
que tienen la capacidad de comunicarse con otros agentes y de actuar con autonomı́a para
obtener beneficio.
1.2.
Propuesta de una arquitectura multi-agente
En esta sección se propone una arquitectura multi-agente que sirva como soporte al portal de comercio electrónico B2C o C2C de propósito general previamente introducido. Dicha
arquitectura debe permitir la implementación de un mercado virtual al que puedan conectarse
10
y asociarse cualquier proveedor o comprador que lo desee, humano o no, y que ofrezca a
los mismos los servicios usuales de este tipo de portales (gestión de usuarios/tiendas, gestión de la jerarquı́a de clases de productos, gestión de productos en venta o subasta en el
portal, gestión de procesos de compras directas y subastas, gestión de mensajes dentro del
portal, gestión de votaciones de usuarios/tiendas en cada uno de los roles posibles (vendedor
o comprador), gestión de incidencias en procesos de compras directas o subastas, sistema de
generación de informes, sistema de búsqueda de productos, usuarios o tiendas,. . . ), para algunos de los cuales se proponen mejoras (p.e. sistema de votaciones que tenga en cuenta las
categorı́as de productos (se pretende asociar votaciones con tipos de productos), sistema de
gestión de la jerarquı́a de clases de productos más preciso, flexible y abierto y que además
ofrezca soporte automático sobre la jerarquı́a, sistema de búsqueda mejorado con posibilidad de hacer búsquedas más avanzadas a partir de descripciones imprecisas de los usuarios,
humanos o no, además de ofrecer asesoramiento dinámico y adaptado al usuario que usa el
sistema basándose en la realidad del mercado), ası́ como otros más novedosos como pueden
ser el servicio de unificación de terminologı́a o vocabulario o el sistema de soporte a la fase de negociación. Además, la arquitectura debe poseer mecanismos para facilitar el uso de
dichos servicios de una manera libre y abierta, y sobre distintas plataformas. También debe
permitir la interoperabilidad de los mismos en la misma y en distintas plataformas, ya que los
servicios pueden estar centralizados o distribuidos.
El aumento en el grado y sofisticación de la automatización del modus operandi de los servicios antes comentados en el lado del portal, buscando un mayor dinamismo, personalización
y adaptabilidad a los rápidos y frecuentes cambios del mercado, conducen a un nuevo modelo
de software [44]. Este modelo se sustenta sobre el concepto de agentes inteligentes, estos se
pueden definir como programas software que pueden desarrollar tareas por sı́ mismo con el
fin de conseguir unos objetivos particulares [86]. Dentro del marco del comercio electrónico
y de la arquitectura propuesta, los agentes se configuran no sólo como el mecanismo empleado para realizar las distintas tareas o servicios antes comentados, sino que también como el
medio para simular el comportamiento de los compradores y vendedores que intervienen en
el proceso [12, 36, 48]. Asimismo, los sistemas multiagente se presentan como el ambiente
en el que todos estos agentes conviven y colaboran para realizar las tareas para los cuales
11
han sido diseñados. El uso de este tipo de sistemas facilita el reparto de responsabilidades, la
heterogeneidad y la concurrencia y distribución.
Actualmente, el comercio electrónico mediado por agentes se encuentra todavı́a en sus
etapas más tempranas, constituyendo estos una fauna variada carente de un sistema de clasificación ampliamente aceptado. Si bien, acontecimientos como la aparición de metodologı́as
para el diseño de sistemas multiagente (AAII, Gaia, Agent UML, DESIRE, Casiopea, MaSE. . . ) o la aparición en 1996 de la organización Foundation for Intelligent Physical Agents
(FIPA) [40] con el objetivo de promover unas especificaciones para facilitar la interoperabilidad entre los sistemas de agentes y proporcionar un lenguaje de comunicación estándar a
nivel de agentes, denominado Agent Communication Language (ACL) y ontologı́as que estructuran el significado de los mensajes, están facilitando el crecimiento y desarrollo de la
tecnologı́a para crear nuevas formas de comercio electrónico.
La primera decisión relevante fue basar el diseño del sistema propuesto en este trabajo
en el conjunto de estándares definidos por el comité FIPA [40] para la difusión de sistemas
multi-agente. La adopción de este enfoque como punto de partida para el diseño del sistema de comercio electrónico tiene dos objetivos principales: i) garantizar la interoperabilidad
con otros sistemas multi-agente diseñados de acuerdo a las guı́as definidas por FIPA, y ii)
proporcionar un conjunto de servicios de gestión básicos comunes a cualquier aplicación
desarrollada a partir de este sistema de propósito general (en este trabajo en particular, el
dominio de aplicación es el comercio electrónico). Desde un punto de vista abstracto, FIPA
define tres servicios básicos comunes a cualquier sistema multi-agente desarrollado mediante
su especificación:
Agent Management System [38]: este componente es el encargado de la gestión general del sistema multi-agente. Para llevar a cabo esta función, lleva un control del ciclo
de vida de los agentes registrados en el sistema y es capaz de instanciar nuevos agentes,
modificar sus descripciones, e incluso eliminarlos del sistema. Ası́ mismo, este componente también proporciona un servicio de páginas blancas al resto de elementos del
sistema multi-agente, es decir, permite la búsqueda de agentes a partir de su nombre o
identificador único.
12
Message Transport Service [39]: este componente proporciona el mecanismo de comunicación entre agentes de una misma plataforma de agentes y entre agentes que
residen en distintas plataformas. No obstante, FIPA también posibilita la comunicación
directa entre agentes sin la necesidad de utilizar este servicio de comunicación intermedio.
Directory Facilitator [38]: este componente, de uso opcional según FIPA, proporciona
un servicio de páginas amarillas a la plataforma de agentes. En otras palabras, permite la
búsqueda de agentes registrados con este servicio a partir de una descripción funcional.
Una de las caracterı́sticas más relevantes del mismo es la posibilidad de que los agentes
se suscriban con este componente, el cual notifica a los mismos cuando un agente se
suscribe, modifica su descripción, o elimina la suscripción con dicho componente.
En nuestra arquitectura multi-agente de propósito general, estos componentes han sido
concebidos como agentes que proporcionan los servicios anteriormente especificados. Por
ejemplo, el Directory Facilitator es un agente que proporciona los servicios relacionados con
la gestión del registro de agentes y con la suscripción de los mismos. Esta elección nos permite
adoptar un enfoque homogéneo en el que todos los componentes del sistema multi-agente
son agentes que proporcionan servicios relevantes para el sistema (ya sean componentes de
gestión de propósito general o componentes especı́ficos del ámbito del comercio electrónico).
A continuación se describirá brevemente la funcionalidad de cada uno de los agentes que
forman parte de la arquitectura multi-agente del sistema de comercio electrónico planteado
en este trabajo, el diseño se ha hecho teniendo en cuenta los distintos procesos o tareas que
se realizan en el portal. En realidad, estos agentes de dominio especı́fico son instancias del
agente de gestión especificado por FIPA y se despliegan a partir del sistema multi-agente de
propósito general anteriormente comentado. Para el usuario humano del portal de comercio
electrónico, el hecho de utilizar un enfoque basado en un sistema multi-agente resulta transparente, ya que el mismo percibe el sistema como un conjunto de servicios que son accesibles
y que pueden proporcionarle un determinado beneficio. Los agentes que forman el sistema
multi-agente son los siguientes:
Agente de gestión del catálogo: este agente es el responsable de mantener el catálogo
13
del portal de comercio electrónico e informar sobre el contenido del mismo. Este catálogo define el conjunto de clases de objetos disponibles en el portal ası́ como los objetos
particulares que pertenecen a cada una de dichas clases. Por lo tanto, sus principales
funciones son las siguientes:
• Garantizar la integridad del mismo, es decir, que en la base de datos que define el
catálogo no existan inconsistencias.
• Comprobar que cuando un vendedor introduce la descripción de un producto en el
portal, dicha descripción es coherente con la definición del producto especificada
en el catálogo.
• Comunicar cuales son las variables que definen cada clase de objeto del portal.
• Interactuar con el administrador del portal para facilitar la interacción con el
catálogo, proporcionando asesoramiento para la creación de nuevos tipos de productos.
Agente recomendador de productos: este agente es el responsable de llevar a cabo
las búsquedas de productos en la base de datos del portal a partir de las descripciones
ofrecidas por un usuario del portal o un agente con capacidad delegada por parte de este
(tı́picamente un agente comprador o un agente vendedor como se verá más adelante).
Las principales misiones de este agente con las siguientes:
• Recibir especificaciones vagas de productos que se desean buscar en el mercado.
• Lograr una especificación representada en un vocabulario común según el catálogo de tipos del portal, para ello interactuará con el Agente Traductor.
• Realizar una búsqueda en el portal teniendo en cuenta la petición recibida.
• Proporcionar una lista ordenada de productos que se asemejen a la especificación
proporcionada como entrada.
• Asesorar en la construcción de la especificación dada como entrada teniendo en
cuenta la realidad del mercado.
14
• Poner en contacto al comprador con los posibles vendedores de los productos que
le interesen, para que pueda comprar el producto, pujar o negociar por él.
• Mantener un histórico de las búsquedas realizadas a nivel general en el portal y
a nivel particular por cada usuario para construir patrones de uso que puedan ser
empleados a la hora de dar asesoramiento.
El agente recomendador hace uso de una estrategia de búsqueda basada en el cálculo de
una distancia global existente entre la especificación dada como entrada y los productos
existentes en la base de datos del sistema teniendo en cuenta las variables valoradas en
la especificación. Este agente se describirá en profundidad en la sección 1.3.2, ası́ como
la estrategia de búsqueda empleada y el algoritmo empleado para dar asesoramiento.
Agente Traductor de especificaciones: este agente será invocado por el agente recomendador de productos, siendo el encargado de traducir las especificaciones a un
vocabulario común y los resultados de las búsquedas y asesoramientos de un vocabulario común a vocabularios particulares. Este agente es necesario para que los agentes se
puedan comunicar entre ellos y no es invocado cuando el uso del agente comprador lo
hace un humano.
Agente de subasta: este agente es el encargado de controlar las subastas en el portal.
Las funciones de este agente son:
• Recibir peticiones de procesos de subastas, a demanda de humanos o agentes
(normalmente agentes vendedores).
• Iniciar procesos de subastas como respuestas a peticiones.
• Controlar que el proceso se desarrolle con normalidad (p.e. comprobando que las
pujas recibidas son reales), verificando que esté activo de manera ininterrumpida
el tiempo establecido para la misma y que se cumplen las condiciones impuestas
(p.e. que el precio de subasta es superior al precio de salida).
• Finalizar los procesos de subastas cuando finalice el tiempo establecido.
15
Agente de venta: este agente es el encargado de controlar las ventas en el portal. Las
funciones de este agente son:
• Recibir peticiones de procesos de ventas, a demanda de humanos o agentes (normalmente agentes vendedores).
• Iniciar procesos de ventas como respuestas a esas peticiones.
• Verificar que la venta se desarrolla como máximo durante el tiempo contratado, y
de manera ininterrumpida.
• Controlar que las órdenes recibidas de compra son reales (usuarios registrados
o agentes compradores con capacidad delegada) y que cumplen las condiciones
impuestas (p.e. que el precio de venta sea el precio establecido, que la orden la
realiza un comprador de un determinado lugar o con una determinada puntuación).
• Finalizar los procesos de venta cuando, o hay un comprador que cierra el trato, o
bien se ha alcanzado la fecha máxima sin lograr cerrar un trato.
Agente buscador de usuarios/tiendas: este agente tiene como misión buscar dentro
del portal aquellos usuarios que venden determinado producto y cumplen unas determinadas condiciones. Las misiones de este agente son:
• Recibir la especificación de un producto o un tipo, ası́ como información adicional
(votaciones recibidas mayor que un determinado valor, que estén localizados en
algún lugar determinado,. . . )
• Proporcionar una lista de vendedores (usuarios/tiendas) que vendan ese producto
y cumplan las restricciones.
Agente de gestión de usuarios: este agente es el encargado de registrar usuarios y tiendas en el portal. También será el encargado de manejar información sobre los usuarios
dentro del portal. Este agente tiene entre sus funciones:
• Registrar usuarios y tiendas.
• Recopilar información sobre las votaciones de estos usuarios en sus dos perfiles
(comprador/vendedor), teniendo en cuenta cada categorı́a.
16
• Registrar la actividad más reciente del usuario con el objetivo de informarle de su
actividad dentro del portal ası́ como poder hacerle recomendaciones futuras.
• Informarle del estado de las transacciones (pendiente de pago, pago recibido, pendiente de envı́o, envı́o realizado, votaciones pendientes que tiene que hacer,. . . ).
Agente generador de informes: este agente es el encargado de generar los informes
que muestran la actividad del portal o de un determinado agente, como por ejemplo
informar sobre el uso del mismo, el número de ventas realizadas en un periodo, el
número de subastas con éxito, etc.
Agente gestor de incidencias: la misión principal de este agente es gestionar las incidencias que se producen en el portal.
Agente controlador de procesos de negociación: es el encargado de comenzar un
proceso de negociación y controlar que esta se desempeña correctamente (siguiendo
unas normas previamente establecidas).
Otros agentes que interaccionan con el portal, aunque no son necesarios son:
Agente vendedor: este agente representa a un vendedor humano en el portal de comercio electrónico y su principal cometido consiste en interactuar con el resto de agentes
del sistema en beneficio de su vendedor humano asociado. Por lo tanto, es responsabilidad de su dueño instanciarlo con el conocimiento que permita al agente comportarse
como el vendedor desee. Las principales funciones de este agente son las siguientes:
• Facilitar su instanciación para satisfacer las pretensiones de su dueño.
• Darse de alta en el sistema y asociarse a su dueño.
• Buscar productos en el portal a partir de especificaciones.
• En base al conocimiento sobre la realidad del portal, generar ofertas de productos atractivas para los compradores, es decir dar de alta productos en el portal y
solicitar su venta o su subasta.
• Participar en procesos de negociación interesantes.
1.3. Servicios de Catálogo, Búsqueda y Recomendación
17
Cada usuario del portal tendrá asociado un agente vendedor, identificado de manera
única dentro del sistema multi-agente subyacente.
Agente comprador: este agente es el encargado de representar a un comprador humano
en el portal con el objetivo de comprar productos que le puedan interesar a su dueño
en base a unas especificaciones dadas por este. Una descripción más detallada de las
funciones de este agente es la siguiente:
• Darse de alta en el portal.
• Ayudar a instanciarse para obtener unos resultados más interesantes para su dueño.
• Ayudar a su dueño a dar especificaciones de productos buscados en el portal, en
base a históricos o sugerencias recibidas por otros agentes del portal.
• Solicitar la búsqueda de productos en base a esas especificaciones construidas.
• Avisar de productos que le puedan interesar a su dueño.
• Interactuar con otros agentes vendedores en los procesos de negociación o de
subasta en los que se encuentre involucrado.
Cada usuario registrado en el portal podrá tener asociado un agente comprador, identificado de manera única dentro del sistema multi-agente.
En la siguiente sección, se describirá en detalle el funcionamiento del agente recomendador de productos, para ello se introducirá previamente en que consiste el catálogo de productos del portal y como se ha materializado.
1.3.
Servicios de Catálogo, Búsqueda y Recomendación
Tı́picamente, los portales de comercio electrónico están compuestos por una colección de
servicios, entre los que caben destacar los servicios de organización y catálogo de productos,
de selección y recomendación de productos y de orientación en el proceso de búsqueda. A
continuación son descritos en detalle los servicios de catálogo, selección, recomendación y
orientación.
18
1.3.1.
Un sistema de categorı́as jerárquico
En el portal propuesto en este trabajo se propone un catálogo de productos que está formado por un conjunto de clases o categorı́as C organizadas de manera jerárquica, donde la clase
general de la jerarquı́a es la clase object, C = {object, c1 , c2 , . . . , cn }. Todas las categorı́as
de productos en el catálogo están asociadas jerárquicamente mediante relaciones de tipo es
un, lo que permite la especificación de categorı́as de productos generales y categorı́as de productos más especı́ficas, las cuáles heredan las propiedades y caracterı́sticas de las categorı́as
generales de las que descienden y además añaden caracterı́sticas especı́ficas sólo poseı́das por
los productos particulares que pertenecen a la categorı́a en sı́. Además, la relación es un por
medio de la cuál todas las categorı́as del catálogo están asociadas es transitiva, lo cual asegura
que cualquier producto del catálogo desciende de la categorı́a object: ∀ ci , ci es un object.
Cualquier producto a la venta en el portal debe pertenecer a una categorı́a ci de las definidas en el catálogo. Por tanto, cada categorı́a está formada por el conjunto de productos
que pertenecen a ella ci = {e1ci , . . . , enci }, donde cada producto ejci ∈ ci está descrito por
medio de un conjunto de atributos Vci = {vc1i , . . . , vcmi } que especifican las diferentes caracterı́sticas o funcionalidades del producto en cuestión. Además, cada variable vcji ∈ Vci
está definida mediante un rango de definición, denotado como RDVcji = {x1 , x2 , . . . , xn } o
RDVcji = [max(vcji ), min(vcji )], el cuál especifica los posibles valores xk que la variable vcji
puede tomar. El rango de definición de una categorı́a de productos ci , denotado como RDVci ,
es definido como la unión de todos los rangos de definición de las variables contenidas en Vci ,
es decir, RDVci = {RDVc1i , . . . , RDVcm
}.
i
En el conjunto de variables que define a la categorı́a object, Vobject , se pueden encontrar
las variables generales usadas normalmente por los portales existentes en la actualidad, como
p.e. el precio, el tipo de producto (nuevo o segunda mano). . .
El catálogo definido debe ser flexible y genérico para permitir libertad a los vendedores
a la hora de definir sus productos y facilidad a los compradores para especificar las caracterı́sticas del producto deseado. Para lograr estos objetivos, se propone la utilización de los
siguientes tipos de datos, los cuáles pueden ser considerados los más comúnmente utilizados
en actividades de comercio electrónico [21].
19
Tipos numéricos con dominio continuo. Este tipo de datos representa toda variable
que puede tomar valores dentro de un rango de números reales, p.e. el precio.
Tipos discretos ordenados o graduados. Este tipo representa toda variable que pueda tomar valores discretos dentro de un conjunto finito con un orden de preferencia
asociado, p.e. estado en el que se encuentra el producto.
Tipos discretos sin orden o nominales. Este tipo representa toda variable que pueda tomar valores discretos dentro de un conjunto finito y sin un orden de preferencia
asociado, p.e. color.
Booleanos o lógicos. Este tipo representa toda variable que pueda tomar tan sólo dos
valores: verdadero o falso, p.e. si el producto posee manual o no.
La generalidad del portal era una de las metas que se ha perseguido, permitiendo la venta/compra de cualquier producto. El sistema de catálogo propuesto logra tener generalidad
debido a que 1) en cualquier instante el administrador puede crear una nueva categorı́a con
las variables que la definen y relacionarla en la jerarquı́a y 2) se puede crear nuevos tipos de
datos para indicar de donde pueden tomar las variables sus valores, estos serán tipos derivados a partir de los tipos antes citados, que son considerados como básicos, pero empleando
restricciones.
Para permitir esta generalidad la base de datos del portal tiene que ser capaz de almacenar
información sobre cualquier categorı́a de producto. Esto es posible gracias al esquema de
base de datos que se muestra en la figura 1.1. Se observa que una categorı́a está relacionada
con 1 o más atributos, permitiendo de esta manera la definición de todas las caracterı́sticas
de una clase de producto. Se observa también que los atributos sólo pertenecen a una clase
de productos, por lo que no van a estar repetidos. Es por ello por lo que en el catálogo se
permite la herencia de atributos de padres a hijos, y además, porque tiene sentido que al
definir una nueva categorı́a se quiera definir algún atributo de la clase padre en la misma.
La tabla Atributo heredado, es la responsable de almacenar esta información (los atributos
que son heredados desde una clase padre a una hija). Ası́ un atributo heredado pertenece a
una única categorı́a y refiere a un único atributo. En la definición del catálogo es necesario
20
que cada atributo esté ligado a un tipo de datos de cara a que cuando el usuario realice las
búsquedas sepa qué tiene que introducir en el campo de búsqueda (un texto o un número). La
tabla Tipo de Dato es la que almacena la información sobre los tipos de datos definidos en el
portal.
Figura 1.1: Esquema base de datos definición de categorı́as.
Hasta aquı́ se ha mostrado la arquitectura del catálogo de la aplicación, pero cabe preguntarse cómo se relacionan los productos con el catálogo. La respuesta se puede encontrar en la
figura 1.2. En ella se observa que cada categorı́a tiene asociados ninguno o varios productos
(asociación entre las tablas Categorı́a y Producto), y que cada producto tiene asociado uno o
varios valores de publicación (Tabla Valor Publicación). Finalmente cada valor de publicación
está asociado a un único atributo que pertenece a una categorı́a. En conclusión el esquema
propuesto abajo permite definir los productos que pertenecen a una categorı́a ası́ como los
valores asociados a cada uno de los atributos de la categorı́a con la que se asocia.
1.3.2.
Sistema de Búsqueda o Selección de Productos
Se ha diseñado un sistema de búsqueda o selección de productos basado en conceptos y
técnicas del campo de la lógica difusa, para permitir a los clientes la especificación de preferencias de búsqueda vagas e imprecisas. Además, se ha tratado de minimizar la cantidad
de datos requerida para definir una búsqueda y de simplificar la naturaleza de éstos con el
objetivo de impactar lo menos posible en la usabilidad del sistema. El servicio de búsqueda
de productos aquı́ descrito basa su proceso en las siguientes etapas: 1) especificación de pre-
21
Figura 1.2: Esquema base de datos para almacenamiento de productos.
Figura 1.3: Valores únicos y rangos, crisp y difusos representados como funciones trapezoidales.
ferencias de búsqueda, 2) búsqueda de productos similares a la especificación del usuario y
3) presentación de resultados al usuario. A continuación se describen en detalle cada una de
ellas.
1.3.2.1.
Especificación de Preferencias de Usuario
La búsqueda de productos comienza con la definición de una descripción de los requisitos
del usuario, es decir éste debe establecer dentro de una clase del sistema de categorı́as de productos del portal (ci ∈ C) y de una manera precisa o vaga que es lo que está buscando. Dicha
descripción es denominada descripción de objeto ideal y denotada como oi . Una descripción
de objeto ideal oi es definida como un subconjunto de variables Vc′i ⊆ Vci extraı́do del con-
22
junto de variables Vci que definen los productos en catálogo pertenecientes a la categorı́a ci .
′
Además, el usuario puede especificar el grado de importancia de cada variable vcji ∈ Vc′i con
un peso Pv′ j ∈ [0, 1].
ci
Para mejorar el proceso de descripción del objeto ideal oi , se propone la utilización de
un servicio de soporte a dicha especificación que recomiende las variables que han sido más
comúnmente utilizadas por el mismo cliente u otros clientes a la hora de buscar productos
dentro de la categorı́a seleccionada ci . El cliente que busca podrá entonces seleccionar algunas
o todas las variables ofrecidas por dicho servicio, además de otras que él considere oportunas.
Una vez seleccionadas las variables que permiten establecer la búsqueda y que definen el
objeto ideal, éstas deben ser valoradas de acuerdo a las expectativas del usuario. Una variable
′
vcji ∈ Vc′i puede ser de cualquiera de los tipos definidos en la sección 1.3.1, por tanto puede ser
valorada seleccionando cualquiera de los valores permitidos definidos en su correspondiente
′
rango de definición RDVcij . Además se podrá determinar un grado de precisión p (p ∈ [0, 1]),
donde p = 1 significa una búsqueda precisa, o crisp, y un grado de precisión p < 1 significa
una búsqueda difusa con un mayor grado de incertidumbre. Cuanto menor es el valor de p
más imprecisión existe en la especificación del valor de dicha variable.
El sistema utiliza un formalismo de representación común para almacenar la valoración
de las variables que describen el objeto ideal, independientemente de los tipos de datos seleccionados. El objetivo de esta representación común es permitir un procesamiento uniforme
de todos los tipos de datos permitidos en el sistema. El formalismo de representación común
utilizado en este trabajo han sido las funciones trapezoidales de parámetros (a, b, c, d), donde el rango [b, c] representa el rango de certeza y [a, b) y (c, d] representan los rangos de
incertidumbre.
La Figura 1.3 muestra cómo las funciones trapezoidales pueden ser utilizadas para la
representación común de los diferentes tipos de datos. Un único valor concreto puede ser
representado mediante el trapezoide (x − a, x, x, x + a), donde x es el valor en sı́, y a viene
determinado por el grado de incertidumbre. Por otro lado, un rango de valores concreto o
difuso puede ser representado como el trapezoide (x−a, x, y, y+a), donde x e y representan el
lı́mite inferior y superior del rango, respectivamente, y a determina la incertidumbre presente
en el rango. El valor del parámetro a pertenece al intervalo [0, max], donde un valor a = 0
23
significa que se trata con un valor o rango concreto o crisp, y un valor de a > 0 significa que se
está tratando con un valor o rango de valores difuso. El valor max especifica el máximo grado
′
de incertidumbre permitido para una variable vcji y es definido a partir de su correspondiente
′
rango de definición RDVcij .
A continuación se describe cómo el usuario debe valorar cada variable utilizada en la
descripción de objeto ideal oi y cómo tales valores son representados como funciones trapezoidales, de acuerdo a sus respectivos tipos de datos.
Tipos numéricos con dominio continuo: Las variables de tipo numérico con dominios
continuos pueden ser valoradas estableciendo un único valor v o un rango de valores
[u, v] junto con un grado de precisión p ∈ [0, 1], cuya función es definir las pendientes
del trapezoide resultante. A partir de esta información, el trapezoide correspondiente se
calcula como se determina a continuación.
Primero se distingue el caso en el que el usuario establece un grado de precisión p = 1.
Este caso define una búsqueda concreta, o crisp. Por lo tanto, el trapezoide resultante
en el caso de especificar un único valor v, será a = b = c = d = v, es decir, un
trapezoide definido sobre un único valor en el dominio continuo. Si por el contrario, el
usuario especifica un rango de valores [u, v], el trapezoide resultante será de la forma
a = b = u y c = d = v, lo que define un rango de valores crisp.
Por otro lado, la especificación un grado de precisión p ∈ [0, 1), define una búsqueda
imprecisa. En este caso, si el usuario especifica un único valor v, el trapezoide resultante
tendrá como parámetros b = c = v, mientras que a y d son obtenidos como muestra la
expresión (1.1).
((max(RDVcji ) − min(RDVcji )) · β) · (1 − m)
−b
m

((max(RDVcji ) − min(RDVcji )) · β) · (1 − m)


d =
+c
m




a
=
(1.1)
donde max(RDVcji ) y min(RDVcji ) devuelven el valor máximo y mı́nimo respectivamente que puede tomar la variable vj en la clase ci , teniendo en cuenta su rango de
definición, RDVcji .
24
De este modo, en el caso de la especificación de valores puntuales con imprecisión, el
grado de incertidumbre contemplada en el trapezoide resultante será directamente proporcional a la amplitud del rango de definición de la variable valorada. El parámetro
β ∈ [0, 1] es delimitador de incertidumbre cuyo objetivo es controlar qué proporción
de la amplitud del rango de definición de dicha variable es considerado para establecer los parámetros a y d que delimitan el grado de imprecisión en el trapezoide. En
los experimentos llevados a cabo en este trabajo se han usado valores de β ≃ 0,05,
comportándose de una manera apropiada. Además, el parámetro m se obtiene a partir
de la especificación de p y es utilizado para calcular ambas pendientes del trapezoide
resultante, tal y como se muestra en la ecuación (1.2):
m = 1 + α − (1 − p)
(1.2)
donde α es un umbral de control para los casos en los que p = 0. En estos casos, el
valor de α sirve para asegurar que m nunca tomará valores m = 0. En los experimentos,
valores de α ≃ 0,01 han sido suficientes y no han alterado el resultado en los casos en
los que p 6= 0.
Por último, en el caso en el que el usuario especifique un rango de valores [u, v] junto
con un grado de precisión p ∈ [0, 1), el trapezoide resultante tendrá como parámetros
b = u y c = v, lo que define el núcleo del conjunto difuso, mientras que los valores de
a y d son calculados a partir de la expresión (1.3).
(c − b) · (1 − m)
−b
m

(c − b) · (1 − m)


d =
+c
m




a
=
(1.3)
En este caso, el grado de imprecisión considerado en el trapezoide resultante será proporcional a la amplitud del núcleo del trapezoide definido (c − b). Ası́, ante el mismo
valor de precisión p, un trapezoide con una mayor amplitud de núcleo tendrá unas pendientes menos pronunciadas que otro trapezoide con menor amplitud de núcleo. Tales
pendientes son calculadas a partir del parámetro m, según la expresión (1.2).
25
Tipos discretos ordenados o graduados: En el caso de variables de este tipo, el usuario
debe especificar una secuencia de valores tomados del dominio discreto que define la
variable y ordenados según un criterio de preferencia. A partir de tal especificación,
el sistema construye un trapezoide para cada uno de los valores seleccionados, donde
a = b = c = d = 0 será el trapezoide resultante para el primer valor de la secuencia (el
preferido), a = b = c = d = 1 para el siguiente y ası́ sucesivamente. Un caso particular
de este tipo, en lo que a representación respecta, en el tipo booleano o lógico, donde
a = b = c = d = 0, será el trapezoide que representa el valor false y a = b = c = d =
1, el valor true.
Tipos discretos sin orden o nominales: En este caso, el usuario debe seleccionar uno
o varios valores del dominio que define la variable sin un orden establecido. En esta
situación no existe la necesidad de crear ningún trapezoide, ya que esta situación significa una especificación de requisitos concreta en la que se busca cualquier objeto que
esté valorado con cualquiera de los valores seleccionados en la variable seleccionada.
1.3.2.2.
Búsqueda de Productos en el Catálogo
Una vez definida la descripción de objeto ideal, el sistema procede a calcular la similitud
entre cada uno de los productos ejci ∈ ci contenidos en el catálogo con la especificación
proporcionada por el usuario. Sin embargo, debido a que la especificación oi es dada en
forma de conjuntos de funciones trapezoidales y los valores que cada producto ejci ∈ ci toma
para cada una de las variables seleccionadas Vc′i ∈ Vci para definir oi son valores puntuales,
tenemos dos opciones a la hora de medir como de similares es cada producto ejci con el
producto ideal oi :
1. Convertir cada valor que define al producto ideal en un único valor y medir la similaridad entre dichos valores y los valores que toma cada producto, empleando para
ello cualquier medida de distancia para variables numéricas lineales, p.e. la distancia
Euclı́dea, Manhattan, Minkowski. . .
2. Representar cada valor de cada variable de cada producto en una función trapezoidal,
si v es el valor tomado por una variable vcji ∈ Vc′i de tipo numérica o discreta con orden
26
en un producto ekci , el trapezoide resultante (a, b, c, d) será a = b = c = d = v. Posteriormente, calcular la distancia que existe entre dicho trapezoide y el trapezoide que
define al objeto ideal, empleando para ello una distancia que nos de dicha información.
En este trabajo se ha optado por la segunda opción, ya que permite el proceso uniforme
de dichos datos para calcular la similitud entre oi y cada ejci ∈ ci en términos de distancias
entre conjuntos trapezoidales.
•
•
•
ο
•
•
•
•
•
•
•
•
•
Figura 1.4: Espacio de referencia para la clase ci .
Desde este punto de vista, el conjunto de rangos de definición RDVc′i relativos al conjunto
de variables seleccionados para definir oi , es decir Vc′i ⊆ Vci , establecen el espacio de referencia en el que se encuentran localizados todos los productos ejci ∈ ci y la definición de objeto
ideal oi (ver Figura 1.4). Ası́, el criterio usado para medir la similitud entre la descripción de
objeto ideal definida por el usuario y cualquier producto ejci ∈ ci del catálogo será la distancia
que existe entre ellos en el espacio de referencia mencionado. Ya que el espacio de referencia
donde todos los productos pertenecientes a la categorı́a ci y la descripción de objeto ideal oi
se encuentran representados tiene dimensión |Vc′i |, para obtener la distancia entre dos puntos
cualesquiera de dicho espacio se debe proceder en dos pasos: i) cálculo de la distancia parcial
′
normalizada entre cualquier ejci ∈ ci y oi respecto a cada variable vcji ∈ Vc′i seleccionada para
definir oi , denotada como dN (oi , ekci , vcji ) y ii) cálculo de la distancia global entre cualquier
27
ejci ∈ ci y oi mediante la agregación de las distancias parciales calculadas en el paso anterior,
denotada como D(oi , ekci ).
Puesto que tanto la descripción de objeto ideal oi como el valor que cada producto ejci ∈ ci
toma en el conjunto de variables Vc′i han sido representados como trapezoides, la distancia
′
parcial entre cualquier ejci ∈ ci y oi con respecto a una variable vcji ∈ Vc′i es obtenida como
una medida de la distancia entre los trapezoides que representan los valores que ejci y oi toman
′
sobre la variable vcji . En este trabajo se ha utilizado la expresión de medida de similitud entre
conjuntos trapezoidales propuesta en [20] por su propiedad de ser fácilmente interpretable.
Según [20], la similitud entre dos conjuntos trapezoidales es medida como el área del trapezoide que existe entre los trapezoides correspondientes a los valores que oi y ejci toman para
′
la variable vcji y se nota como d(oi , ekci , vcji ) (ver Figura 1.5). No obstante, podrı́a ser calculada
mediante cualquier expresión que determine el grado de similitud entre dos conjuntos difusos
trapezoidales.
La normalización de esta distancia parcial se obtiene dividiendo la distancia obtenida
entre la distancia máxima según el rango de definición de la variable que viene dada por
max(RDVcji ) − min(RDVcji ). Se recuerda que max(RDVcji ) y min(RDVcji ) son funciones
que devuelven el valor máximo y mı́nimo respectivamente que puede tomar la variable vj en
la clase ci , teniendo en cuenta su rango de definición, RDVcji . Es decir,
dN (oi , ekci , vcji ) =
d(oi , ekci , vcji )
max(RDVcji ) − min(RDVcji )
(1.4)
Un tratamiento especial requieren las variables cuyo tipo es discreto sin orden, en este
caso se emplea una heurı́stica que determina que la distancia parcial entre oi y cualquier
ejci ∈ ci es 0 si los valores que ambos elementos toman para dicha variable son iguales y 1 en
caso contrario.
Una vez obtenida la distancia parcial normalizada entre oi y cada ejci ∈ ci de acuerdo a
′
cada una de las variables vcji ∈ Vc′i , la distancia global entre ambos elementos es obtenida
como la suma de las distancias parciales calculadas y ponderada por los pesos que el usuario
asoció a cada variable en la etapa de definición de la descripción de objeto ideal. La expresión
(1.5) muestra la ecuación de la distancia global entre oi y ejci .
28
Figura 1.5: La Similaridad entre el valor de una variable cualquiera que define un producto
(izquierda) y el valor especificado por el usuario (derecha) puede verse como el cálculo del
área del conjunto difuso entre (en color gris), en el caso de variables continuas.
D(ej , oi ) =
X
′
dN (ej , oi , vcji ) × PN (vc′ji )
(1.5)
′
∀vcji ∈Vc′i
donde,
P (v ′j )
′
PN (vcji ) = P|V ′ | ci
ci
′x
x=1 P (vci )
(1.6)
′
es el peso normalizado asociado con la variable vcji .
Se verifica que el valor calculado de distancia global entre cada producto del catálogo
ej ∈ ci y el objeto o producto ideal oi es un valor entre cero y uno, es decir D(ej , oi ) ∈ [0, 1].
1.3.2.3.
Organización de Resultados y Recomendación de Productos
Finalmente, el proceso de búsqueda o selección de productos devuelve una lista de elementos ejci ∈ ci ordenados de forma creciente de acuerdo a sus valores de distancia global
con la especificación de objeto ideal proporcionada por el usuario oi . Obviamente, aquellos
productos con un menor valor de distancia global son potencialmente más interesantes para
el usuario, ya que son más similares a la especificación oi , por lo que son recomendados antes
que aquellos productos con un mayor valor de distancia.
29
Sin embargo, uno de los aspectos claves en cualquier sistema de recomendación es la
capacidad de proporcionar orientación al usuario acerca de qué productos le pueden interesar,
más que mostrarle un valor real expresando una distancia entre dos puntos en un espacio de
referencia. Ası́ pues, para mejorar este aspecto se ha desarrollado un servicio de clasificación
de productos en base al interés que pueden tener para el usuario, en el que cada elemento es
asociado a una clase según su valor de distancia global con oi . Estas clases pueden ser vacı́as
y no tienen porque ser excluyentes. Esto es conseguido mediante la definición de una variable
lingüı́stica llamada Utilidad que puede tomar tres valores lingüı́sticos: Lo que buscas, Casi lo
que buscas y Lejos de lo que buscas. Ası́ pues, cada elemento ej es asociado con una o dos
de estas etiquetas por medio de un proceso de fuzificación del valor de distancia D(ej , oi ),
informando al usuario acerca de lo interesante que tal elemento puede ser para él. El dominio
de definición de la variable Utilidad se encuentra en el dominio de la distancia global, es
decir, en el intervalo [0, 1], y cuyas etiquetas están organizadas de tal forma que los menores
valores son asignados a las etiquetas más interesantes para el usuario. La definición de estas
etiquetas que ha dado un buen resultado se puede ver en la Figura 1.6.
Figura 1.6: Dominio de definición de la variable utilidad
1.3.3.
Adquisición de Conocimiento del Mercado
En este punto, el portal es capaz de recomendar a los usuarios aquellos productos del portal que son más similares a la especificación de objeto ideal proporcionada por ellos mismos.
Sin embargo, las preferencias especificadas por éstos son realizadas a veces con el desconoci-
30
miento del mercado en relación al producto que desean comprar, lo que conlleva en ocasiones
a la especificación de preferencias que no se corresponden con la oferta que existe en realidad.
Este problema es conocido con el nombre de sobre estimación de productos y ocurre cuando
los usuarios desconocen las relaciones existentes entre las caracterı́sticas que describen una
determinada categorı́a de productos. Un ejemplo de tal relación podrı́a ser las cámaras fotográficas más caras son aquellas con mayor resolución de imagen. A partir del análisis de
estas relaciones se podrı́a inferir conocimiento del tipo: por la misma cantidad de dinero puede comprar una cámara con mayor resolución de imagen, lo que podrı́a ser útil para orientar
al usuario a la hora de definir preferencias de búsqueda más realistas con respecto a la oferta
existente en el portal y ası́ ser más consciente del conjunto de caracterı́sticas que puede exigir
y a qué coste.
El descubrimiento de estas relaciones podrı́a hacerse como es usual en otros campos,
empleando modelos que son usados para analizar la base de datos. Los procesos de análisis
basados en modelos implica un conocimiento previo de las relaciones a buscar [71]. En la
actualidad, se están proponiendo métodos que no necesitan de estos modelos, y que trabajan
con muy poco conocimiento a priori sobre el problema concreto. Estos métodos están basados
en algoritmos de aprendizaje automático supervisados [18, 60], que o han sido diseñados
especı́ficamente para este problema o bien han sido adaptaciones de algoritmos existentes
a las particularidades del problema y por supuesto a los datos con los que se trabaja. Estos
algoritmos tienen como objetivo descubrir reglas de asociación, que son reglas que denotan
asociaciones interesantes entre variables. Estas reglas toman la forma X −→ Y donde X e
Y son conjuntos de variables [6]. Para indicar cómo de interesantes son las reglas aprendidas
se suelen emplear dos medidas, 1) número de ejemplos en los que la asociación se cumple, y
2) fortaleza de la asociación.
En esta sección, se propone una metodologı́a para desarrollar un sistema de descubrimiento de estas reglas que muestre este tipo de relaciones útiles para ayudar a los usuarios de
portales (C|B)2C durante sus búsquedas. Dicha metodologı́a está basada en un algoritmo de
aprendizaje supervisado.
Con el algoritmo de aprendizaje supervisado se pretende inferir los patrones estructurales
existentes en los productos del mercado presentes en la base de datos manejada por el portal,
31
pero dadas en un formato comprensible para los usuarios. Con estos requisitos en mente, se
propone el uso de reglas difusas de tipo Mamdani, SI-ENTONCES [59] como formalismo
de representación de las reglas de asociación que expresan las relaciones existentes entre
un conjunto de variables o atributos y una variable objetivo. Además se pretende hacer uso
de la información que se ha calculado hasta este momento, es decir las distancias calculadas
teniendo en cuenta las preferencias especificadas por el usuario, y la variable lingüı́stica usada
para agrupar los resultados.
A continuación en esta sección se describen cual va a ser el conjunto de datos de entrenamiento del algoritmo de aprendizaje, el tipo de reglas que se pretenden aprender, el procedimiento de aprendizaje llevado a cabo por este y la forma en la que el conocimiento inferido
es usado para dar orientación al usuario.
1.3.3.1. Conjunto de Datos de Entrenamiento
"#$%
&"#$%
!
Figura 1.7: Valor de la variable precio en la especificación oi y valores tomados para la misma variable por dos productos diferentes exci y eyci . Las distancias parciales dN (exci , oi , vcji ) y
dN (eyci , oi , vcji ) tendrán el mismo valor, aunque la primera será negativa para expresar el hecho de que la valoración en la variable precio del producto exci es menor que la valoración
establecida en la especificación oi .
Los métodos de aprendizaje supervisado tienen como objetivo inferir un conjunto de relaciones entre las variables que describen a un conjunto de ejemplares con una determinada
clase. En el caso del problema actual, no existe una clase y el objetivo es inferir un conjunto de reglas que describan las relaciones entre las variables que definen los productos de
una determinada categorı́a ci , para ello se hace necesaria la utilización de un conjunto de entrenamiento construido a partir de los productos pertenecientes a dicha categorı́a en las que
aparezcan esas relaciones.
32
Tal como fue descrito en la sección anterior, el portal propuesto en este trabajo calcula
la similitud entre cada producto ekci ∈ ci de la base de datos con el ideal oi definido por el
usuario. Este proceso procede primero calculando la distancia parcial dN (ekci , oi , vcji ) entre un
producto ekci y el objeto ideal oi de acuerdo a cada variable vcji ∈ Vc′i para luego obtener la
distancia global D(ekci , oi ) mediante la agregación de las distancias parciales. El resultado del
primero de los dos pasos anteriores da lugar a la tabla de distancias parciales, en la que cada
producto ekci ∈ ci se encuentra representado en una fila de la tabla y cada variable vcji ∈ Vc′i en
una columna. La intersección de una fila k con una columna j, contiene un valor xk,j ∈ [0, 1]
que es la distancia parcial normalizada entre el producto ekci y oi de acuerdo a la variable vcji
(donde 1 ≤ k ≤ |ci | y 1 ≤ j ≤ |Vc′i |), es decir xk,j = dN (ekci , oi , vcji ).
A partir de esa información, se pretende aprender reglas del tipo: SI vc1i es IGUAL o MAS
o MUCHO MAS y vc2i es IGUAL y . . . ENTONCES vcxi es MUCHO MENOS. La cual puede
ser transformada en una recomendación del tipo: Por MUCHO MENOS vcxi puedes conseguir
IGUAL, MAS o MUCHO MENOS vc1i e IGUAL vc2i y . . . . Donde los valores IGUAL, MAS,
MENOS, MUCHO MAS y MUCHO MENOS son los valores lingüı́sticos que puede tomar
una variable definida sobre el intervalo [0, 1], ya que (dN (x, y, vcji )) ∈ [0, 1]).
Sin embargo, la medida de similitud propuesta en [22] utilizada para calcular las distancias parciales tiene ciertos problemas cuando es aplicada con los objetivos actuales. Tal y
como es ilustrado en la Figura 1.7, los trapezoides correspondientes a cada valor de la variable precio en los productos exci y eyci se encuentran a la misma distancia del trapezoide
correspondiente al valor de dicha variable en la especificación de objeto ideal oi . El hecho
de que la medida propuesta en [22] devuelva el mismo valor para ambos casos hace imposible distinguir qué producto está valorado con un menor o mayor valor en dicha variable,
ya que las distancias parciales calculadas se encuentran en el intervalo [0, 1]. Para solucionar
este problema, se propone amplificar este intervalo para que las distancias parciales puedan
tomar valores dentro del rango [−1, +1]. De este modo, un valor positivo significa que el
valor tomado por el producto ekci es mayor que el especificado en la descripción oi y un valor
negativo el caso contrario. Ası́, valores cercanos a cero significan que ambas valoraciones son
IGUALES, mientras que valores mayores o menores que cero significan que la valoración del
producto es MAS o MENOS respectivamente, que la valoración definida en la especificación
33
Tabla 1.1: Tabla de distancias parciales entre cada producto ekci y la especificación oi conforme
a cada variable vcji ∈ Vc′i .
ekci
vc1i
vc2i
...
vcmi
e1ci
x1,1
x1,2
...
x1,m
e2ci
..
.
x2,1
..
.
x2,2
..
.
...
..
.
x2,m
..
.
enci
xn,1
xn,2
...
xn,m
oi , y valores muy lejanos a cero y próximos a −1 y 1 implican valores MUCHO MENOS o
MUCHO MAS que el establecido en oi .
Convertir los valores de distancia parcial xk,j ∈ [0, 1] contenidos en la tabla de distancias parciales para que tomen valores dentro del rango [−1, +1] es un proceso trivial y nada
costoso computacionalmente. Para ello, cada valor xk,j de la tabla de distancias parciales es
′
multiplicado por −1 si el valor de la variable vcji tomado por el ejemplar ekci es menor que el
tomado por la especificación oi y por 1 en caso contrario.
La Tabla 1.1 muestra la forma de la tabla de distancias parciales normalizadas y polarizadas. Valores xk,j cercanos a cero significan que el producto ekci es muy similar a la especificación oi con respecto a la variable vcji , por lo que a partir de esta tabla se puede inferir
qué atributos hacen a un producto determinado similar o no a la especificación de usuario.
Ası́ pues, este conjunto de datos servirá al proceso de entrenamiento del algoritmo de aprendizaje presentado en la siguiente sección para la inferencia del conocimiento requerido.
1.3.3.2.
Inferencia de Reglas
Se ha trabajado con un sistema MISO (Múltiples entradas y una única salida), cuyo modelo viene dado por un conjunto de entrenamiento θ = {e1 , e2 , . . . , em } donde m es el número
de ejemplos del conjunto de entrenamiento. Cada ei tendrá la siguiente forma:
ei = (xi,1 , xi,2 , . . . , xi,n : xi,t )
siendo xk,j = dN (ekci , oi , vcji ).
34
Figura 1.8: Dominio de definición de la variable dist (DDVdist ).
Todas las variables que aparecen en el ejemplo pertenecen al conjunto de variables seleccionadas por el usuario para definir la descripción de objeto ideal oi .
El objetivo que se persigue es aproximar la función:
Ω : dN (ekci , oi , vc1i ) × dN (ekci , oi , vc2i ) × . . . × dN (ekci , oi , vcji ) −→ dN (ekci , oi , vcti )
que modela las relaciones entre las variables por medio de un conjunto de reglas difusas. Éstas
serán construidas por medio de un proceso de generalización sobre los ejemplos particulares
ei ∈ θ. El algoritmo usado obtiene un conjunto de reglas difusas, con la siguiente forma:
SI vc1i toma valores de ZD1,dist Y vc2i toma valores de ZD2,dist Y . . .
ENTONCES vcti toma el valor x.
las cuales proporciona información acerca de las relaciones existentes entre las distancias de
los valores de las variables vcji que se encuentran en el antecedente de la regla y la distancia
con el valor de la variable objetivo vcti en el consecuente.
El conjunto ZDj,dist toman sus valores del conjunto P(DDVdist ). Siendo DDVdist el
dominio de definición de la variable lingüı́stica dist,
DDVdist = {M U CHOM EN OS, M EN OS, IGU AL, M AS, M U CHOM AS}
La figura 1.8 muestra el dominio de definición de la variable lingüı́stica dist y como se
define cada etiqueta.
35
Cada variable vcti utilizada como variable objetivo define una nueva función Ω, lo que implica la necesidad de ejecutar de nuevo el algoritmo para obtener una aproximación adecuada
a la nueva función definida. Ası́ pues, es de gran importancia utilizar como variables objetivo
aquellos atributos que sean de mayor importancia para el usuario que define la búsqueda, ya
que el conocimiento inferido será un conjunto de patrones que relacionan el resto de variables en vcji ∈ Vc′i con la variable objetivo vcti . Para automatizar el proceso de definición de las
funciones Ω a aproximar, el sistema propone al usuario la utilización de aquellas variables
vcji ∈ Vc′i a las que les ha sido asignado un mayor valor de peso Pvcj como variables objetivo.
i
La idea principal del algoritmo es construir un conjunto de reglas iniciales muy particulares, partiendo del conjunto de ejemplos de entrenamiento, y generalizar esas reglas obtenidas
pero siempre apoyándose en evidencias. El método propuesto es una adaptación del algoritmo
de aprendizaje automático propuesto en [19], y consta de los siguientes pasos:
1. Convertir los ejemplos de entrenamiento en reglas particulares. En este paso, cada ejemplo del conjunto de entrenamiento será convertido en una regla difusa. En ella, cada valor de cada variable de entrada xk,j es fuzificado teniendo en cuenta DDVdist , asimismo
la salida del ejemplo xk,t será también fuzificada empleando para ello DDVdist .
El resultado de la etapa de preproceso es un conjunto de reglas Ri con la siguiente
forma:
A1,k , . . . , An,k : At,k
donde Aj,k = maxk {µk (xk,j )} es la etiqueta lingüı́stica perteneciente al dominio de
definición de la variable dist cuyo valor de la función de pertenencia de xk,j es máximo.
Esta regla es la forma abreviada de la regla:
Ri : SI vc1i toma el valor ZD1i = {A1,k } Y . . . Y vcni toma el valor ZDni = {An,k }
ENTONCES vcti toma el valor At,k .
Ası́ pues, esta etapa puede verse como una traducción de los valores xk,j ∈ [−1, +1]
encontrados en la tabla de distancias parciales al dominio de definición de la variable
dist.
36
2. Construir reglas generales. Una vez finalizada la primera etapa del proceso, en la que se
ha convertido cada producto ekci ∈ ci en una regla inicial, el objetivo a hora es obtener
reglas con la siguiente forma:
Ri : SI vc1i toma valores de ZD1i Y vc2i toma valores de ZD2i Y . . . Y vcni toma valores
de ZDni ENTONCES vcti toma el valor At,k
donde cada ZDij es un conjunto de valores tomados del dominio de definición de la
variable dist y asociados disyuntivamente. Para ello, el algoritmo trata de subsumir las
reglas iniciales generadas en reglas más generales que formarán el conjunto de reglas
definitivas proporcionadas al usuario. Para una descripción más en detalle del algoritmo
utilizado en este trabajo, se recomienda la lectura de [46, 19].
Brevemente, el proceso de generalización procede de la siguiente manera:
a) Tomar una regla Ri : (ZD1i , ZD2i , . . . , ZDni : At,k ) del conjunto de reglas iniciales.
b) Si la regla tomada es subsumida en alguna de las reglas del conjunto de reglas definitivas, dicha regla es ignorada. Ir al paso 3. Una regla Ri : (ZD1i , ZD2i , . . . , ZDni : At,k )
′
es subsumida en otra regla Rj : (ZD1j , ZD2j , . . . , ZDnj : At,k ), si se cumple
′
que: ZD1i ⊆ ZD1j , ZD2i ⊆ ZD2j , . . . , ZDni ⊆ ZDnj y At,k = At,k .
c) Para cada variable vcji en la regla tomada Ri :
/ ZDji .
1) Para cada etiqueta Ax,y ∈ DDVdist , tal que Ax,y ∈
Amplificar la regla Ri con Ax,y tal que ZDji = ZDji ∪ {Ax,y }, si es
posible.
d) Añadir la regla amplificada en el conjunto de reglas definitivas.
e) Si quedan reglas sin haber sido consideradas en el conjunto de reglas iniciales, ir
al paso 3. En otro caso, finalizar.
Referido al proceso de ampliación, se tiene que resaltar que una regla Ri puede ser
amplificada en otra regla Ri′ con una nueva etiqueta si las siguientes tres condiciones se
cumplen:
37
′
a) No existe una regla Rj : (ZD1j , ZD2j , . . . , ZDnj : At,k ) en el conjunto de reglas iniciales que verifique ZD1j ⊆ ZD1i′ , ZD2j ⊆ ZD2i′ ,. . . ,ZDnj ⊆ ZDni′ y
′
At,k 6= At,k .
b) Ri puede ser amplificada con una nueva etiqueta Ax,y en una variable vcji si existe
otra etiqueta Ax,k ∈ ZDji que verifique que dN (Ax,y , Ax,k , vcji ) ≤ α, siendo α un
valor de umbral definido a priori.
c) Existe una evidencia dentro del conjunto de ejemplos que confirma la ampliación.
1.3.3.3.
Interpretación de Reglas
Tras la ejecución del algoritmo, el resultado es un conjunto de reglas de la siguiente forma:
Ri : SI vc1i toma valores de {Igual,Más} Y vc2i toma valores de {Menos} Y vc3i toma valores
de {Más,Mucho Más} ENTONCES vcti toma el valor {Menos} < x % >
De la interpretación de la regla Ri se pueden extraer las siguientes conclusiones: “Existen
productos con un valor de vcti ligeramente inferior al especificado en oi que tienen un valor
de vc1i similar o ligeramente superior al establecido por el usuario, un valor de vc2i ligeramente inferior y un valor de vc3i superior al establecido por el usuario”. El término < x % >
especifica el porcentaje de productos de la categorı́a ci que con cubiertos por la regla.
Aunque las reglas proporcionadas son de por sı́ auto explicativas, se ha incorporado un
servicio de traducción de reglas para proporcionar al usuario el conocimiento inferido por
medio de oraciones del tipo:
Por Menos vcti puedes conseguir Igual o Más vc1i Y Menos vc2i Y Más o Mucho Más vc3i .
Esto es conseguido fácilmente ya que es simplemente un reordenamiento de la regla y un
cambio de terminologı́a empleando los valores que toman las variables en las reglas inferidas
con significado para el usuario, lo que permite la creación de frases en lenguaje natural que
son fácilmente comprensibles para los usuarios y les permite redefinir su búsqueda.
38
1.4.
Un ejemplo para mostrar el funcionamiento del agente
En esta sección se va a mostrar como funciona el sistema de búsqueda y selección ante
la demanda de un usuario. El producto que se va a buscar es una cámara de fotos digital.
El portal cuenta en su base de datos con una categorı́a Cámaras de Fotos Digitales a la que
pertenecen 119 productos. Esta categorı́a está descrita por medio de 51 variables (p.e. precio,
marca, resolución monitor. . . ).
También se mostrará como funciona el sistema recomendador y la forma en la que el
sistema aprende las relaciones entre las variables que definen una cámara con el objetivo de
dar orientación a un usuario a la hora de dar la especificación del producto buscado.
Como entrada el usuario proporcionará una descripción vaga sobre la cámara que desea,
para ello seleccionará las variables precio, peso, longitud y especificará el valor buscado, es
decir Vc′i = {precio, peso, longitud}, que es un subconjunto del conjunto de variables que
definen a las cámaras de fotos digitales dentro del portal. Esta descripción es la denominada
descripción de objeto ideal, oi .
Supongamos que la especificación (oi ) dada es la siguiente:
P recio = 400,
P eso = 300,
Longitud = 18.
todos ellos con una precisión del 95 % y un peso Normal (0,33).
La representación interna de oi será la siguiente:
P recio = (397, 31; 400; 400; 402, 69),
P eso = (298, 39; 300; 300; 301, 61),
Longitud = (17, 67; 18; 18; 18, 32).
Una vez definida la descripción de objeto ideal, se calcula la similitud entre cada una
de las cámaras de fotos digitales del catálogo, ∀ejci ∈ Categorı́a de fotos digitales, con la
39
especificación proporcionada por el usuario oi . Esto se muestra en las tablas 1.2 y 1.3, pero
teniendo en cuenta el valor absoluto de los valores que se muestran.
El proceso de búsqueda o selección de productos devuelve una lista de cámaras digitales
ordenadas de forma creciente de acuerdo a sus valores de distancia global. Esta lista es entonces divida como se estableció en la sección 1.3.2.3, agrupados en grupos haciendo uso de
una variable lingüı́stica Utilidad:
Lo que buscas:
Casi lo que buscas:
Lejos de lo que buscas: { Sony Cyber-shot DSC-T200, Panasonic Lumix DMC TZ5,
Canon Ixus 970 IS, Canon PowerShot A650 IS, Olympus MJU 770 SW, Panasonic Lumix DMC-FX100EG-S, Sony Ericsson Cyber-SHOT DSC-T2B, Casio Exilim EX-Z
1080, Casio Exilim EX-Z1200, Panasonic Lumix DMC-TZ3, Canon IXUS 950 IS, Canon Digital IXUS 860 IS, Nikon Coolpix P5100, Panasonic Lumix DMC-FX55, Canon
Digital IXUS 75 / Powershot SD750 /, Ricoh Caplio R7, Sony Cybershot DSC-W200,
Nikon Coolpix S200, Olympus MJU 840, Olympus FE-300, Panasonic Lumix DMCFX33, Casio Exilim EX-Z100, Sony Ericsson Cyber-SHOT DSC-T20, Sony Cybershot
DSC-W90, Casio Exilim EX-Z200, Canon Digital IXUS 70, Sony Ericsson CyberSHOT DSC-W130, Fujifilm FinePix F480, Olympus FE-230 / X-790, Sony Ericsson
Cyber-SHOT DSC-W80S, Kodak EasyShare V1003, Casio Exilim EX-Z80, Olympus
FE-280, Fujifilm FinePix Z10FD, Panasonic Lumix DMC-FX10, Pentax Optio S10,
Panasonic Lumix DMC-FX12, Canon PowerShot A720 IS, Kodak Easyshare M753,
Canon PowerShot A590 IS, Olympus FE-310 / X-840, BenQ DC C740I, Nikon Coolpix L15, Canon PowerShot A570 IS, Panasonic Lumix DMC-FZ8, Olympus FE-210,
Canon Powershot A560, Kodak Easyshare C813, Kodak EasyShare C613, Fujifilm FinePix S5800, Olympus SP-550 UZ, Kodak Easyshare C713, Panasonic Lumix DMCFZ18, Fujifilm FinePix S8000FD, Canon PowerShot S5 IS, Sony Cybershot DSC-H9,
Toshiba Camileo 6IN1 PX1333E-1CAM, Sony Cyber-shot DSC-T70,Panasonic Lumix
DMC-FZ50 }
40
Como se puede observar, con la especificación que hizo el usuario no hay productos en
la base de datos que satisfagan las restricciones impuestas, ya que no hay ninguna cámara
que se agrupe dentro de los grupos Lo que buscas o Casi lo que buscas. Es ejemplo claro de
desconocimiento del mercado.
A continuación se muestra como el sistema aprende reglas para orientar al usuario a la
hora de hacer una especificación más realista teniendo en cuenta el mercado.
A partir de la información obtenida sobre las distancias cuando se realizó la búsqueda, se
obtiene el conjunto de reglas iniciales que se muestra en la tabla 1.4, 1.5 y 1.6.
Tabla 1.4: Conjunto de reglas iniciales para el Precio.
Ri
Peso
Longitud
Precio
Repeticiones
Porcentaje
R1
MUCHO MENOS
MÁS
MUCHO MENOS
23
38,9
R2
MUCHO MENOS
MUCHO MÁS
MUCHO MENOS
14
23,7
R3
MUCHO MENOS
IGUAL
MUCHO MENOS
12
20,3
R4
MUCHO MÁS
MUCHO MÁS
MUCHO MENOS
6
10,1
R5
IGUAL
MUCHO MÁS
MUCHO MENOS
3
5
R6
MUCHO MÁS
MUCHO MÁS
IGUAL
1
1,6
Tabla 1.5: Conjunto de reglas iniciales para el Peso.
Ri
Peso
Longitud
Precio
Repeticiones
Porcentaje
R1
MUCHO MENOS
MÁS
MUCHO MENOS
23
38,9
R2
MUCHO MENOS
MUCHO MÁS
MUCHO MENOS
14
23,7
R3
MUCHO MENOS
IGUAL
MUCHO MENOS
12
20,3
R4
MUCHO MENOS
MUCHO MÁS
MUCHO MÁS
6
10,1
R5
MUCHO MENOS
MUCHO MÁS
IGUAL
3
5,0
R6
IGUAL
MUCHO MÁS
MUCHO MÁS
1
1,6
41
Tabla 1.6: Conjunto de reglas iniciales para la Longitud.
Ri
Precio
Peso
Longitud
Repeticiones
Porcentaje
R1
MUCHO MENOS
MUCHO MENOS
MÁS
23
38,9
R2
MUCHO MENOS
MUCHO MENOS
MUCHO MÁS
14
23,7
R3
MUCHO MENOS
MUCHO MENOS
IGUAL
12
20,3
R4
MUCHO MENOS
MUCHO MÁS
MUCHO MÁS
6
10,1
R5
MUCHO MENOS
IGUAL
MUCHO MÁS
3
5
R6
IGUAL
MUCHO MÁS
MUCHO MÁS
1
1,6
El proceso de generalización sobre las reglas iniciales da como fruto el conjunto de reglas
generales que se muestra en las tablas 1.10, 1.8 y 1.9
Tabla 1.7: Conjunto de reglas generales para el Precio.
Ri
Peso
R1
MUCHO MENOS
Longitud
IGUAL, MÁS,
Precio
Repeticiones
Porcentaje
MUCHO MENOS
49
83
MUCHO MÁS
R2
MUCHO MÁS
MUCHO MÁS
MUCHO MENOS
6
10,1
R3
IGUAL
IGUAL, MÁS,
MUCHO MENOS
3
5
IGUAL
1
1,6
MUCHO MÁS
R4
MUCHO MÁS
MUCHO MÁS
Tabla 1.8: Conjunto de reglas generales para el Peso.
Ri
Precio
Longitud
Peso
Repeticiones
Porcentaje
R1
MUCHO MENOS
IGUAL, MÁS
MUCHO MENOS
35
59,3
R2
MUCHO MENOS
MUCHO MÁS
MUCHO MENOS
14
23,7
R3
MUCHO MENOS
MUCHO MÁS
MUCHO MÁS
6
10,1
R4
MUCHO MENOS
MUCHO MÁS
IGUAL
3
5
R5
IGUAL
MUCHO MÁS
MUCHO MÁS
1
1,6
42
Tabla 1.9: Conjunto de reglas generales para la Longitud.
Ri
Precio
Peso
Longitud
Repeticiones
Porcentaje
R1
MUCHO MENOS
MUCHO MENOS
MÁS
23
38,9
R2
MUCHO MENOS
MUCHO MENOS
MUCHO MÁS
14
23,7
R3
MUCHO MENOS
MUCHO MENOS
IGUAL
12
20,3
R4
MUCHO MENOS
MUCHO MÁS
MUCHO MÁS
6
10,1
R5
MUCHO MENOS
IGUAL
MUCHO MÁS
3
5
R6
IGUAL
MUCHO MÁS
MUCHO MÁS
1
1,6
De este conjunto se usan las reglas siguientes para construir un consejo u orientación:
Tabla 1.10: Conjunto de reglas generales para el Precio.
Ri
Peso
R1
MUCHO MENOS
Precio
Repeticiones
Porcentaje
MUCHO MENOS
49
83
Longitud
IGUAL, MÁS,
MUCHO MÁS
Estas reglas son convertidas en los siguientes consejos:
Existen 49 productos con mucho menos Precio que el que usted busca, por mucho
menos valor de Peso especificado/a, Y por el mismo o un poco más o mucho más valor
de Longitud especificado/a
El usuario en base a estos consejos modifica su especificación inicial, a una nueva:
P recio = 200,
P eso = 180,
Longitud = 18.
todos ellos con una precisión del 95 % y un peso Normal (0,33).
Lo cual hace que el sistema le recomiende los siguientes productos:
Lo que buscas: {Sony Cyber-shot DSC-T200}
43
Casi lo que buscas: {Olympus MJU 770 SW, Casio Exilim EX-Z1200, Canon IXUS
950 IS, Casio Exilim EX-Z 1080 Panasonic Lumix DMC-FX55, Canon Digital IXUS
860 IS, Canon Digital IXUS 75 / Powershot SD750 /, Ricoh Caplio R7, Sony Ericsson
Cyber-SHOT DSC-T2B, Nikon Coolpix S200, Olympus MJU 840, Sony Cybershot
DSC-W200}
Lejos de lo que buscas: {Olympus FE-300, Panasonic Lumix DMC-FX33, Casio Exilim EX-Z100, Sony Ericsson Cyber-SHOT DSC-T20, Sony Cybershot DSC-W90, Panasonic Lumix DMC-FX100EG-S, Casio Exilim EX-Z200, Canon Digital IXUS 70,
Sony Ericsson Cyber-SHOT DSC-W130, Fujifilm FinePix F480, Olympus FE-230 / X790, Sony Ericsson Cyber-SHOT DSC-W80S, Kodak EasyShare V1003, Canon Ixus
970 IS, Casio Exilim EX-Z80, Olympus FE-280, Fujifilm FinePix Z10FD, Panasonic
Lumix DMC-FX10, Pentax Optio S10, Panasonic Lumix DMC-FX12, Kodak Easyshare M753, Canon PowerShot A590 IS, Olympus FE-310 / X-840, Panasonic Lumix
DMC-TZ3, BenQ DC C740I, Nikon Coolpix P5100, Nikon Coolpix L15, Canon PowerShot A720 IS, Canon PowerShot A570 IS, Panasonic Lumix DMC TZ5, Olympus
FE-210, Canon Powershot A560, Kodak Easyshare C813, Kodak EasyShare C613, Kodak Easyshare C713, Canon PowerShot A650 IS, Toshiba Camileo 6IN1 PX1333E1CAM, Panasonic Lumix DMC-FZ8, Fujifilm FinePix S5800, Olympus SP-550 UZ,
Fujifilm FinePix S8000FD, Panasonic Lumix DMC-FZ18, Sony Cybershot DSC-H9,
Canon PowerShot S5 IS, Sony Cyber-shot DSC-T70, Panasonic Lumix DMC-FZ50}
Este ejemplo puede ser probado en el portal (http://personal.oreto.inf-cr.uclm.es/apps/ezoco/).
44
Tabla 1.2: Conjunto de entrenamiento con distancias parciales entre cada producto ekci y la
especificación oi conforme a cada variable vcji ∈ Vc′i .
ekci
Precio
Peso
Longitud
Distancia Global
Sony Cyber-shot DSC-T200
-0,185
-0,181
0,015
0,127
Panasonic Lumix DMC TZ5
-0,1
-0,136
0,15
0,129
Canon Ixus 970 IS
-0,107
-0,231
0,074
0,137
Canon PowerShot A650 IS
-0,109
0
0,303
0,137
Olympus MJU 770 SW
-0,184
-0,231
0,019
0,145
Panasonic Lumix DMC-FX100EG-S
-0,143
-0,242
0,054
0,147
Sony Ericsson Cyber-SHOT DSC-T2B
-0,153
-0,272
0,016
0,147
Casio Exilim EX-Z 1080
-0,252
-0,175
0,02
0,149
Casio Exilim EX-Z1200
-0,181
-0,236
0,034
0,15
Panasonic Lumix DMC-TZ3
-0,206
-0,108
0,15
0,155
Canon IXUS 950 IS
-0,19
-0,215
0,066
0,157
Canon Digital IXUS 860 IS
-0,181
-0,231
0,062
0,158
Nikon Coolpix P5100
-0,134
-0,159
0,182
0,158
Panasonic Lumix DMC-FX55
-0,191
-0,25
0,039
0,16
Canon Digital IXUS 75 / Powershot SD750 /
-0,211
-0,27
0,011
0,164
Ricoh Caplio R7
-0,2
-0,263
0,041
0,168
Sony Cybershot DSC-W200
-0,182
-0,252
0,073
0,169
Nikon Coolpix S200
-0,238
-0,279
0,003
0,173
Olympus MJU 840
-0,203
-0,271
0,047
0,173
Olympus FE-300
-0,2
-0,295
0,031
0,175
-0,23
-0,268
0,031
0,176
-0,203
-0,301
0,024
0,176
Sony Ericsson Cyber-SHOT DSC-T20
-0,219
-0,276
0,037
0,177
Sony Cybershot DSC-W90
-0,214
-0,28
0,038
0,177
-0,21
-0,288
0,036
0,178
Canon Digital IXUS 70
-0,248
-0,279
0,01
0,179
Sony Ericsson Cyber-SHOT DSC-W130
-0,218
-0,282
0,038
0,179
Fujifilm FinePix F480
-0,252
-0,255
0,039
0,182
Olympus FE-230 / X-790
-0,247
-0,311
-0,011
0,19
Sony Ericsson Cyber-SHOT DSC-W80S
-0,252
-0,28
0,038
0,19
45
Tabla 1.3: Conjunto de entrenamiento con distancias parciales entre cada producto ekci y la
especificación oi conforme a cada variable vcji ∈ Vc′i . Continuación de la Tabla 1.2
ekci
Precio
Peso
Longitud
Distancia Global
Kodak EasyShare V1003
-0,267
-0,252
0,054
0,191
Casio Exilim EX-Z80
-0,254
-0,319
0,007
0,193
Olympus FE-280
-0,268
-0,306
0,007
0,194
Fujifilm FinePix Z10FD
-0,276
-0,303
0,005
0,195
-0,259
-0,279
0,047
0,195
Pentax Optio S10
-0,261
-0,303
0,023
0,195
-0,268
-0,279
0,047
0,198
-0,248
-0,159
0,189
0,199
Kodak Easyshare M753
-0,276
-0,295
0,039
0,203
-0,246
-0,199
0,18
0,208
Olympus FE-310 / X-840
-0,272
-0,255
0,098
0,208
BenQ DC C740I
-0,318
-0,255
0,062
0,212
Nikon Coolpix L15
-0,27
-0,295
0,09
0,218
-0,277
-0,199
0,196
0,224
Panasonic Lumix DMC-FZ8
-0,185
0,015
0,485
0,228
Olympus FE-210
-0,306
-0,284
0,098
0,229
Canon Powershot A560
-0,287
-0,215
0,199
0,233
Kodak Easyshare C813
-0,298
-0,26
0,152
0,237
Kodak EasyShare C613
-0,315
-0,26
0,152
0,242
Fujifilm FinePix S5800
-0,23
0,01
0,498
0,246
Olympus SP-550 UZ
-0,162
0,103
0,477
0,247
Kodak Easyshare C713
-0,315
-0,26
0,174
0,249
-0,104
0,095
0,556
0,252
Fujifilm FinePix S8000FD
-0,137
0,175
0,487
0,266
Canon PowerShot S5 IS
-0,118
0,239
0,474
0,277
Sony Cybershot DSC-H9
-0,128
0,17
0,538
0,279
Toshiba Camileo 6IN1 PX1333E-1CAM
-0,286
-0,252
0,421
0,319
Sony Cyber-shot DSC-T70
-0,193
1
0,171
0,455
-0
0,588
0,987
0,525
46
Capı́tulo 2
Objetivos
El objetivo de este Proyecto Fin de Carrera consiste en desarrollar un portal de comercio electrónico que amplı́e notablemente las funcionalidades de la herramienta de comercio
electrónico (e-Market Tool [61]), y que además ofrezca soporte para que en un futuro puedan
interactuar con el mismo agentes del tipo ACOMDI [43] y AVENDI [52].
El diseño del portal se va a hacer de manera genérica ofreciendo los siguientes servicios:
Sistema de gestión de usuarios (con las operaciones de alta, baja y modificación).
Venta de productos de manera directa y mediante puja.
Sistema de clasificación de los productos que se ofertan en el portal. El catálogo es
gestionable (alta, baja y modificación de categorı́as).
Gestión de los tipos de datos del catálogo (creación, modificación y eliminación).
Gestión del prestigio de cada usuario mediante votaciones.
Búsqueda de productos de diversas formas: mediante términos o palabras clave, mediante términos imprecisos (empleando variables lingüı́sticas, lógica difusa), mediante
la especificación de caracterı́sticas precisas, mediante navegación en categorı́as de productos o mediante combinaciones de las anteriores.
Gestión de la información disponible de los productos que ofrecen los vendedores en la
base de datos de e-ZOCO, con actualización automática de la misma. De esta forma, se
47
48
Capı́tulo 2. Objetivos
pretende minimizar el problema de la existencia de información obsoleta en el portal,
garantizando que la información que obtiene un comprador es información actualizada.
Recuperación de información relevante sobre un producto de la base de datos. El proceso de búsqueda interpreta la petición realizada por un comprador con objeto de recuperar la información que más se ajusta a la especificación del usuario, proporcionando
información que le ayuda a tener una visión real del mercado del producto.
Poner en contacto a compradores y vendedores vı́a correo electrónico.
Alertas de compra-venta mediante correo electrónico.
Gestión del correo electrónico generado por la aplicación.
Generación de informes de estado del portal en cuanto a búsquedas y transacciones de
venta y subasta.
Gestión de parámetros de configuración de la aplicación.
Visualización del estado de los usuarios.
Algoritmo de aprendizaje en el buscador que ayuda a compradores a localizar el producto deseado.
Permitir a compradores y vendedores enviar mensajes a otros compradores y vendedores.
Visualización de productos adquiridos en los distintos mercados (para compradores).
Visualización de productos puestos a la venta (para vendedores).
Visualización de mensajes recibidos (tanto de otros usuarios registrados como del administrador).
Registro de incidencias (para compradores y vendedores).
Mecanismo de recuperación del estado de las subastas ante una caı́da del sistema para
garantizar que ninguna subasta queda sin adjudicar.
49
Otro objetivo del proyecto es proponer una arquitectura multi-agente para comercio electrónico, que permita liberar al usuario de todo el proceso de compra (la propuesta puede
localizarse en la sección 1.2). Con este sistema multi-agente el usuario únicamente tendrı́a
que especificar su producto ideal y la máxima cantidad que está dispuesto a pagar, y un agente
software, con dicha información, se encargarı́a de llevar a cabo el proceso de adquisición del
mismo, independientemente del mercado del producto (venta directa o subasta).
50
Capı́tulo 2. Objetivos
Capı́tulo 3
Metodologı́a de desarrollo
3.1. El Proceso Unificado como metodologı́a de desarrollo software . . . . . . . . . . . . 51
3.1.1.
Dirigido por casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.2.
Centrado en la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.3.
Iterativo e incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.1.4.
El ciclo de vida del Proceso Unificado . . . . . . . . . . . . . . . . . . . . . 54
3.1.5.
Adaptación de la metodologı́a al presente Proyecto . . . . . . . . . . . . . . 56
3.2. Metodologı́a de desarrollo de base de datos . . . . . . . . . . . . . . . . . . . . . . . 57
3.1.
3.2.1.
Fase 1. Modelado Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.2.
Fase 2. Diseño lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2.3.
Fase 3. Diseño fı́sico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
El Proceso Unificado como metodologı́a de desarrollo
software
El Proceso Unificado [47] es un proceso de desarrollo software, definido como un conjunto de actividades necesarias para transformar los requerimientos de los usuarios en un sistema
software. Puede ser adaptado a cualquier tipo de sistema software. Está basado u orientado a
componentes, de modo que el sistema software que resulta de la aplicación de este proceso
está formado por componentes que se comunican por medio de interfaces. Usa UML para la
51
52
Capı́tulo 3. Metodologı́a de desarrollo
construcción de los planes y diagramas del sistema software. Tiene tres caracterı́sticas fundamentales que lo hacen destacar como proceso de desarrollo software: dirigido por casos de
usos, centrado en la arquitectura e iterativo e incremental.
3.1.1.
Dirigido por casos de uso
Un caso de uso se corresponde con un fragmento de la funcionalidad del sistema que da al
usuario un valor o resultado. Su función es capturar los requisitos funcionales. Todos los casos
de uso del sistema unidos forman el modelo de casos de uso que describen la funcionalidad
completa del sistema.
La estrategia de casos de uso trata de responder a la pregunta ¿Qué tiene que hacer el
sistema para cada usuario?. Ello obliga a pensar no sólo en términos de funciones, si no
además en términos de valores a los usuarios. Los casos de uso, no son únicamente una
herramienta que nos permite capturar los requisitos del sistema, si no que permite dirigir su
diseño, implementación y pruebas, de ahı́ que se pueda decir que los casos de uso dirigen el
proceso de desarrollo. Al final del desarrollo se obtienen varios modelos (de casos de uso, de
implementación, etc.) relacionados entre sı́, ya que uno se obtiene a partir de otro.
En conclusión dirigido por casos de uso significa que el proceso de desarrollo sigue un
flujo que comienza en los casos de uso y que va derivando en diagramas y componentes cada
vez más detallados que a su vez derivan en otros diagramas y componentes hasta la obtención
del sistema.
3.1.2.
Centrado en la arquitectura
El concepto de arquitectura software agrupa los aspectos dinámicos y estáticos más significativos y crece a partir de las necesidades de la empresa y de los usuarios interesados y
de cómo es reflejado en los casos de uso. Sin embargo, también influyen en la misma muchos otros factores tales como la plataforma software sobre la que se va a ejecutar el sistema
(sistema operativo, base de datos, etc.), la reutilizabilidad de los componentes construidos,
consideraciones de despliegue, sistemas obsoletos y requisitos no funcionales (rendimiento,
confiabilidad, etc.). En definitiva, la arquitectura es la vista de todo el diseño en la que se
53
destacan todos los aspectos fundamentales y se ocultan los detalles.
La arquitectura está fuertemente ligada a los casos de uso debido a que las funcionalidades que representan los casos de uso deben estar ubicadas en alguna parte del sistema.
Resumidamente la arquitectura representa varios aspectos:
1. Un esbozo aproximado de la arquitectura, comenzando con la parte de la misma que no
es dependiente de los casos de uso, como por ejemplo la plataforma de ejecución.
2. Trabaja con subconjuntos de casos de uso identificados que representan las funcionalidades clave del sistema en construcción. Cada caso de uso es especificado en detalle e
implementado en términos de sistemas y componentes.
3. Cuando los casos de uso maduran, la mayor parte de la arquitectura es descubierta, lo
que a su vez lleva también a la maduración de los casos de uso.
3.1.3.
Iterativo e incremental
El desarrollo de un producto software es una dura tarea que puede llevarse a cabo a lo
largo de varios meses e incluso más de un año. Debido a esto, es una buena práctica dividir el trabajo en pequeñas piezas o miniproyectos. Cada miniproyecto es una iteración que
lleva a un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo y los
incrementos en el crecimiento del producto. Para una mayor efectividad las iteraciones deben
ser controladas, o dicho de otra manera, deben ser seleccionadas y ejecutadas de una manera
planificada, de ahı́ que a una iteración se la denomine miniproyecto.
Los desarrolladores basan la selección de qué tiene que ser implementado en dos factores:
1. La iteración se refiere a un conjunto de casos de uso que juntos amplı́an la usabilidad
del producto tal y como se ha definido hasta la fecha.
2. La iteración aborda los riesgos más importantes.
Las sucesivas iteraciones se construyen en el desarrollo de artefactos desde el estado que
se alcanzó en la iteración anterior. Esto es lo que se conoce como un miniproyecto, que
comienza en los casos de uso y continúa con el análisis, diseño, implementación y pruebas.
54
Un incremento no tiene que ser necesariamente aditivo, especialmente en las primeras
fases del ciclo de vida, en el que los desarrolladores pueden reemplazar el modelo con uno
más detallado. En fases más avanzadas los incrementos son tı́picamente aditivos.
En cada iteración los desarrolladores identifican y especifican casos de uso relevantes,
crean un diseño usando una arquitectura como guı́a, implementan el diseño en componentes
y verifican que los componentes satisfacen los casos de uso. Si una iteración alcanza sus objetivos se continúa con la siguiente iteración, en caso contrario se deben revisar las decisiones
tomadas en la iteración y probar de nuevo.
Para alcanzar el máximo rendimiento en el desarrollo, el equipo de proyecto seleccionará únicamente las iteraciones requeridas para alcanzar los objetivos del proyecto. Un proyecto con éxito normalmente seguirá un curso de desarrollo, en el que habrá pocas desviaciones desde el curso de desarrollo planificado inicialmente.
3.1.4.
El ciclo de vida del Proceso Unificado
Para entender el ciclo de vida del proceso unificado es necesario entender tres conceptos:
1. Ciclo: es un desarrollo software que concluye con una versión completa del producto
(release) lista para ser entregada. Esta versión dispone de componentes de código fuente
listos para ser compilados y ejecutados, manuales, la especificación de requisitos, casos
de uso, especificaciones no funcionales y casos de prueba, ası́ como la arquitectura y
los modelos visuales.
2. Fase: es una parte de un ciclo. En el Proceso Unificado cada ciclo se descompone en
cuatro fases: iniciación, elaboración, construcción y transición.
3. Iteración: es una parte de una fase. En el proceso unificado cada fase está dividida en
iteraciones.
El Proceso Unificado se compone de ciclos (ver figura 3.1). Los ciclos sucesivos al primero comenzarán estudiando los artefactos generados en el ciclo anterior: modelo de casos de
uso, modelo de análisis, modelo de diseño, modelo de implementación, modelo de despliegue,
modelo de pruebas y la arquitectura de representación.
55
Figura 3.1: Ciclo de un sistema software desde el punto de vista del PUD
El propósito de cada modelo es el siguiente:
1. Modelo de casos de uso: proporciona la respuesta a la pregunta ¿Qué debe hacerse para
cada usuario?
2. Modelo de análisis: refina los casos de uso con un mayor nivel de detalle y realiza
una asignación inicial del comportamiento del sistema a un conjunto de objetos que
ofrezcan dicho comportamiento.
3. Modelo de diseño: define la estructura estática del sistema como subsistemas, clases e
interfaces y los casos de uso como colaboraciones entre subsistemas, clases e interfaces.
4. Modelo de implementación: incluye los componentes de código fuente y el mapeo de
las clases con los componentes.
5. Modelo de despliegue: define los nodos fı́sicos de computadores y el mapeo de los
componentes a dichos nodos.
6. Modelo de prueba: describe los casos de prueba que verifican los casos de uso.
Cada ciclo se subdivide en fases (ver figura 3.2). Las fases en las que se subdivide cada
ciclo son: iniciación, elaboración, construcción y transición. Cada fase concluye en un hito.
Un hito se define por medio de la disponibilidad de un conjunto de artefactos (modelos o
documentos generados durante el desarrollo). Los hitos tienen varios propósitos: ayudar a la
toma de decisiones para no pasar a la siguiente fase antes de que no haya concluido cierto
trabajo, facilitar el seguimiento del progreso del trabajo y seguir la pista del tiempo y el
esfuerzo dedicados a cada fase, permitiéndonos obtener datos útiles para otros proyectos.
56
El propósito de cada una de las fases es el siguiente:
Fase de iniciación: proporciona la respuesta a preguntas tales como ¿Qué va a hacer
principalmente el sistema para cada uno de los principales usuarios del sistema? ¿Cómo
podrı́a ser la arquitectura? ¿Cuál será el plan a ejecutar y cuál será el coste de desarrollo
del producto? Durante esta fase se desarrolla un modelo de casos de uso y se identifican
y priorizan los riesgos.
Fase de elaboración: se identifican la mayorı́a de casos de uso del sistema, se refinan
a un nivel mayor de detalle y se diseña la arquitectura. Al final de la fase el Jefe de
Proyecto está en condiciones de elaborar un plan de actividades y estimar los recursos
estimados para el proyecto.
Fase de construcción: durante esta fase se construye el producto.
Fase de transición: cubre el perı́odo durante el que el producto se considera una versión
beta. Incluye actividades tales como manufacturado, entrenamiento de los usuarios del
producto, establecimiento de ayuda en lı́nea, corrección de defectos tras la entrega.
Cada una de las fases se subdivide a su vez en iteraciones (ver figura 3.3) con el objetivo
de simplificar las acciones a llevar a cabo.
En conclusión, el ciclo de vida del Proceso Unificado está compuesto por ciclos, que
a su vez se componen de fases que se subdividen en iteraciones.
3.1.5.
Adaptación de la metodologı́a al presente Proyecto
Es necesario adaptar la metodologı́a al presente Proyecto Fin de Carrera simplificándola por razones de tiempo y recursos, de manera que la adaptación quedarı́a de la siguiente
manera:
Se va a ejecutar un sólo ciclo.
Cada ciclo va a estar formado por tres fases: iniciación, elaboración y construcción.
Habrá fases formadas por una iteración.
3.2. Metodologı́a de desarrollo de base de datos
57
Figura 3.2: Fases del Proceso Unificado de Desarrollo
Los modelos visuales que se van a generar son los siguientes:
• Modelo de Casos de Uso.
• Modelo de Análisis.
• Modelo de Clases que va a sustituir a los modelos de Diseño e implementación.
Planificación de actividades (priorización de casos de uso).
3.2.
Metodologı́a de desarrollo de base de datos
La aplicación que se describe en el presente proyecto requiere de una base de datos robusta
y fiable, por ello se aplica una metodologı́a orientada a bases de datos que ayude a conseguir
este objetivo. Más en concreto, la metodologı́a de desarrollo de bases de datos que se aplica
se caracteriza por abordar el diseño de la base de datos en tres fases [28]:
Fase 1. Modelado Conceptual: se centra en obtener una buena representación de los
recursos de información, con independencia de usuarios o aplicaciones (Sistema Gestor
58
Figura 3.3: Iteraciones del Proceso Unificado de Desarrollo
de Base de Datos), y sin realizar consideraciones sobre la eficiencia. Para ello se utiliza
un Modelo de Datos.
Fase 2. Diseño lógico: consiste en transformar el esquema conceptual obtenido en la
etapa anterior, adaptándolo al modelo de datos en el que se apoya el SGBD que se va a
utilizar.
Fase 3. Diseño fı́sico: su objetivo es conseguir una implementación, lo más eficiente
posible, del esquema lógico.
3.2.1.
Fase 1. Modelado Conceptual
En esta primera fase se emplea el modelo Entidad/Interrelación que fue desarrollado por
Chen en el año 1976 [24] [23] [32] [29] y que se basa en la creación de un diagrama Entidad/Interrelación aplicando los conceptos asociados a dicho modelo. En el diagrama obtenido
se representan todas las entidades que intervienen en el sistema de Base de Datos y las relaciones existentes entre ellas. Se crea a partir de los requisitos que debe satisfacer el sistema y
está formado por los siguientes elementos:
Elementos estáticos:
• Entidades: cualquier objeto real o abstracto que existe en la realidad y acerca del
cual queremos almacenar información en la base de datos.
3.2. Metodologı́a de desarrollo de base de datos
59
• Interrelaciones: asociación, vinculación o correspondencia entre entidades.
• Dominios y valores: conjunto de valores homogéneos con un nombre que lo identifica.
• Atributos: propiedad o caracterı́stica asociada a una determinada entidad y, por
tanto, común a todas las ocurrencias de esa entidad; nombre, cantidad, categorı́a
profesional, edad, cargo, etc., son ejemplos de atributos.
Restricciones:
• Inherentes: sólo permiten establecer interrelaciones entre entidades, no estando
admitidas entre entidades e interrelaciones ni entre interrelaciones
• De integridad:
◦ Sobre valores: se establecen mediante la definición de dominio.
◦ Estructurales: referidas a atributos (identificadores y cardinalidades) e interrelaciones (cardinalidades mı́nima y máxima, dependencias en existencia e
identificación, etc.).
3.2.2.
Fase 2. Diseño lógico
Una vez definidas las entidades que intervendrán en el sistema, la información asociada
a cada una de ellas, y las relaciones existentes entre ellas, se construye el Modelo Relacional
[30] [33] de la base de datos.
El Modelo Relacional fue propuesto por primera vez en el año 1970 por Codd [25], y
dispone de los siguientes elementos:
Dominios y Atributos: un dominio es un conjunto nominado, finito y homogéneo de
valores atómicos y un atributo es la interpretación de un determinado dominio en una
relación.
Relaciones: están formadas por un nombre, una cabecera (conjunto de pares atributodominio), un cuerpo (conjunto de tuplas), un esquema (constituido por el nombre y la
cabecera) y un estado (formado por el esquema y el cuerpo de la relación).
60
Restricciones.
• Inherentes: las impuestas por el propio modelo como por ejemplo que ningún
atributo que forme parte de la clave primaria puede tomar valores nulos.
• Semánticas: clave primaria, unicidad, obligatoriedad, integridad referencial (clave
ajena), restricciones de rechazo, disparadores.
Para construir el Modelo Relacional se parte del diagrama entidad/interrelación obtenido
en la fase anterior y se tienen en cuenta las siguientes reglas principales[31]:
Todo tipo de entidad se transforma en una relación.
Todo tipo de interrelación N:M se transforma en una relación.
Para todo tipo de interrelación 1:N se realiza lo que se denomina propagación de clave
(regla general), o se crea una nueva relación.
3.2.3.
Fase 3. Diseño fı́sico
Al finalizar esta etapa debe haberse seleccionado la base de datos del mercado que utilizará el sistema y deben abordarse los llamados requisitos no funcionales tales como los
relativos al rendimiento.
Algunos aspectos importantes para la mejora del rendimiento son los citados en [62]:
Si una tabla que contiene cientos de miles de filas debe resumirse en un informe diario, puede agregar a la tabla una o varias columnas que contengan datos previamente
agregados para utilizarlos sólo en dicho informe.
Las bases de datos pueden normalizarse en exceso. Esto significa que la base de datos
se define con un gran número de tablas pequeñas interrelacionadas. Cuando la base
de datos procesa los datos de estas tablas, debe realizar muchas más operaciones para
combinar los datos relacionados. Este procesamiento adicional puede repercutir negativamente en el rendimiento de la base de datos. En esos casos, una reducción de la
normalización de la base de datos para simplificar procesos complejos puede mejorar
el rendimiento.
Capı́tulo 4
Aplicación de la metodologı́a
4.1. Catálogo de requisitos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2. Elección de la Tecnologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2.1.
Sistema Gestor de Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2.2.
Lenguaje de programación . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2.3.
Configuración de la conexión con la base de datos . . . . . . . . . . . . . . . 72
4.2.4.
Tecnologı́a web empleada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2.5.
Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.2.6.
Diseño de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.2.7.
Herramientas para la creación de los diagramas y documentación . . . . . . . 81
4.3. Diseño de la base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3.1.
Modelo Entidad Interrelación . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3.2.
Modelo Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.3.3.
Modelo fı́sico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.4. Aplicación del Proceso Unificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.4.1.
Plan de iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.4.2.
Resumen del Proceso Unificado aplicado al Proyecto . . . . . . . . . . . . . 114
4.4.3.
Relaciones entre los Modelos implementados . . . . . . . . . . . . . . . . . 115
4.4.4.
Arquitectura del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
En este capı́tulo se aplica la metodologı́a descrita en el capı́tulo anterior y se muestran los
principales resultados obtenidos. Antes de nada es necesario aclarar los requisitos del sistema,
como sugieren tanto las metodologı́as de desarrollo software como las de desarrollo de bases
61
62
Capı́tulo 4. Aplicación de la metodologı́a
de datos. Posteriormente se siguen los pasos descritos en dichas técnicas de desarrollo de
software.
4.1.
Catálogo de requisitos del sistema
La aplicación desarrollada en este Proyecto Fin de Carrera es una aplicación web de comercio electrónico, con herramientas administrativas para gestionarla, que permite tanto a
usuarios particulares como a empresas anunciar sus productos para venta directa y/o subasta.
Ası́ mismo, permite a potenciales compradores buscar los productos que mejor satisfacen sus
necesidades, o a las empresas que pueden suministrar dichos productos.
A continuación se detallan las funcionalidades de la aplicación, presentándolas agrupadas
semánticamente:
El Sistema de Gestión de Cuentas de Usuario:
R1. Este sistema puede ser utilizado por cualquier usuario del sistema.
R2. Un usuario anónimo puede crear una cuenta en el sistema como particular o como
empresa. Durante el registro el usuario debe indicar qué rol va a desempeñar en el
sistema: comprador, vendedor o ambos.
R3. Cualquier usuario que posea una cuenta en el sistema podrá modificar y eliminar
su cuenta.
R4. Cuando un usuario elimina su cuenta, el sistema elimina todos los productos asociados a dicha cuenta.
R5. Existe un sistema de autenticación para que compradores, vendedores y administradores se identifiquen ante el sistema y se les muestren todas sus opciones.
R6. Un usuario anónimo recibe sugerencias del sistema sobre poblaciones, provincias
y calles al registrarse.
R7. Un administrador puede crear una cuenta de administrador.
R8. Cuando un usuario se registra con éxito debe activar su cuenta antes de acceder al
portal. De este modo obliga a los usuarios a especificar una dirección de correo
4.1. Catálogo de requisitos del sistema
63
electrónico válida si realmente está interesado en el portal.
R9. Aquellos usuarios con perfil administrador pueden ver y eliminar usuarios registrados en el portal y el estado de su cuenta (activa o no activa).
El Sistema de Gestión de Clases de Productos:
R10. A este sistema solo podrá acceder el administrador.
R11. Un administrador puede dar de alta, modificar y eliminar una clase de producto.
R12. Dar de alta una clase de producto implica crear una nueva clase con un nombre,
indicar qué clase es la clase padre y crear los atributos que la conformen.
R13. Los atributos de las clases tienen un tipo de datos asociado, por lo que este sistema
permite la creación, modificación y borrado de tipos de datos.
R14. Los tipos de datos deben poder compartirse entre las distintas clases de productos.
R15. Las clases de Productos forman un árbol jerárquico.
R16. Al crear una categorı́a de productos como una categorı́a hija de otra, deben poder
heredarse los atributos de la categorı́a padre en la categorı́a hija si el usuario lo
desea.
R17. Debe existir una categorı́a raı́z que no pueda modificarse ni eliminarse, y que tenga
un mı́nimo de atributos comunes a todos los tipos de productos. Esta categorı́a
permite que en cualquier momento se puedan registrar productos para los que no
existe una categorı́a especı́fica.
El sistema de Gestión de productos:
R18. Los usuarios con rol de vendedor son los únicos que pueden registrar productos
en el sistema.
R19. Al dar de alta un producto en el sistema debe indicarse a qué mercado se destina:
venta directa, puja o ambos.
R20. Un producto registrado en el sistema, que esté destinado al mercado de venta
directa, tiene una fecha de caducidad definida por el administrador, a partir de la
cual, si no ha sido vendido será eliminado del sistema.
64
R21. Un producto registrado en el sistema, que esté destinado al mercado de subasta
no podrá tener una fecha de fin de puja que exceda el perı́odo de caducidad de
productos definido por el administrador.
R22. Un producto registrado en el sistema, que esté destinado al mercado de subasta
no podrá tener una fecha de fin de puja que exceda el perı́odo de caducidad de
productos definido por el administrador.
R23. La adquisición de productos del portal sólo podrá realizarla un comprador y con
las siguientes condiciones:
a) Un comprador puede pujar por un producto del mercado de subastas.
b) Un comprador puede comprar un producto del mercado de venta directa.
c) Antes de poder realizar una compra, el comprador debe realizar una búsqueda
en el portal y seleccionar la opción de compra o puja.
d) El sistema envı́a un mensaje al propietario del producto por el que se interesa
el comprador para que se pongan en contacto.
e) Los productos del mercado de venta directa adquiridos (ya sean del mercado de subasta o del mercado de venta directa) no aparecerán en sucesivas
búsquedas.
f ) Al pulsar sobre la opción de puja o compra de uno de los productos de la
lista generada por el buscador se mostrarán todos los detalles del producto,
ası́ como información relativa a la valoración media de las votaciones del propietario en la clase de producto a la que pertenece. Además, se debe mostrar
el número de transacciones en el que no ha sido votado el propietario del producto (asociado a la categorı́a a la que pertenece el producto localizado en la
búsqueda).
Sistema de Gestión de Tipos de Datos de Atributos:
R24. Respecto a los tipos de datos, deben existir tipos de datos derivados y tipos de datos primitivos. Los tipos de datos primitivos vienen proporcionados por el sistema
y no son modificables. Los tipos derivados son creados por el administrador.
65
R25. Los tipos de datos primitivos son los siguientes:
a) Números Reales.
b) Números Enteros.
c) Texto.
R26. Los tipos derivados podrán ser definidos por el administrador a partir de los tipos
primitivos aplicando las siguientes restricciones:
a) Mayor que (<).
b) Menor que (>).
c) Mayor o igual que (<=).
d) Menor o igual que (>=).
e) Conjunto.
f ) Intervalo (en el caso de Tipos de Datos no textuales).
R27. Un ejemplo de definición de tipo derivado podrı́a ser la de los números reales
positivos, que se definirı́a a partir del tipo primitivo real con la restricción >=0.
R28. Un tipo derivado puede ser eliminado o modificado por un administrador, y en ese
caso se informará a los propietarios de los productos afectados.
R29. Al eliminar un tipo derivado se eliminarán los atributos que tengan dicho tipo y
también las valoraciones de productos que existan de dicho atributo.
El Sistema de Configuración de Parámetros de la aplicación:
R30. A este sistema únicamente podrá acceder el administrador.
R31. Los parámetros que maneja este sistema son:
a) Periodo de vigencia de cualquier producto en el portal.
b) Periodo de vigencia de las transacciones finalizadas.
c) Periodo de vigencia de los mensajes de los usuarios.
d) Periodo de generación de informes de búsqueda.
e) Periodo de resumen de las votaciones de los usuarios.
66
f ) Configuración del servidor de correo.
g) Credenciales para acceder al servidor de correo.
h) Una serie de parámetros que afectan al buscador difuso.
El Sistema de Búsqueda:
R32. Pueden realizar búsquedas tanto usuarios anónimos como registrados (compradores, vendedores y administradores).
R33. Hay dos modos de búsqueda, el modo por defecto y el modo avanzado.
R34. En ambos modos de búsqueda se mostrarán productos pertenecientes tanto al mercado de venta directa como al de subastas. No obstante, el usuario podrá indicar
que se busquen únicamente productos del mercado de subastas o del mercado de
venta directa.
R35. Hay varios tipos de búsqueda:
a) Búsqueda de texto.
b) Búsqueda por exploración de categorı́as.
c) Búsqueda mediante la especificación de valores precisos para caracterı́sticas
de productos.
d) Búsqueda mediante la especificación de valores aproximados para caracterı́sticas de productos (empleando conjuntos difusos).
e) Búsqueda mediante la combinación de la búsqueda por categorı́as con la
búsqueda de texto.
R36. El modo por defecto incluye los tipos de búsqueda de texto, por exploración de
categorı́as y mediante la combinación de las anteriores.
R37. El modo avanzado incluye los tipos de búsqueda mediante la especificación de
valores precisos o aproximados para caracterı́sticas de productos.
R38. Una búsqueda de productos dará como resultado una lista de productos que cumpla los requisitos de búsqueda del usuario según el tipo de búsqueda utilizado.
R39. Se mostrará la siguiente información por cada uno de los productos encontrados:
67
a) Tı́tulo o nombre del producto.
b) Si el producto pertenece al mercado de venta directa se mostrará la fecha de
caducidad.
c) Si el producto pertenece al mercado de subasta se mostrará la fecha de fin de
subasta.
d) Precio del producto.
e) Si el producto pertenece al mercado de venta directa aparecerá un enlace que
muestre toda la información del producto y permita comprarlo.
f ) Si el producto pertenece al mercado de subasta aparecerá un enlace que muestre toda la información del producto y permita hacer una puja.
g) Si el producto pertenece al mercado de pujas aparecerá un texto indicando el
número de pujas que se han realizado para el producto.
R40. La lista de productos resultado de la búsqueda debe poder ordenarse en base a los
siguientes criterios:
a) En búsquedas por defecto:
a) Precio del producto.
b) Por fecha de existencia en el portal (fecha de caducidad en el mercado de
venta directa o fecha de fin de puja en el mercado de subastas).
R41. Cuando un usuario realiza una búsqueda, se deben guardar los siguientes datos:
a) En búsquedas en modo por defecto:
a) La categorı́a buscada.
b) En búsquedas en modo avanzado:
a) Las distancias (nivel de seguridad) y valoraciones especificadas por el
usuario.
R42. Un usuario comprador podrá realizar búsquedas de empresas por categorı́as y visualizar los productos asociados a la empresa y a la categorı́a.
R43. En búsquedas difusas el usuario tendrá que indicar el grado de seguridad sobre
cada una de las caracterı́sticas que desee consultar sobre el producto. En el caso
68
de los tipos de datos texto-conjunto, el usuario podrá ordenar los elementos del
conjunto para proporcionar las distancias al sistema en base a ese orden.
R44. En búsquedas difusas se permitirá al usuario especificar el grado de importancia
de las distintas caracterı́sticas que desea buscar.
El Sistema de Gestión de Mensajes:
R45. Tanto compradores como vendedores podrán acceder al sistema de gestión de
mensajes.
R46. Compradores y vendedores podrán consultar los mensajes que les han sido enviados por otros usuario o bien automáticamente por el sistema.
R47. Compradores y vendedores podrán borrar los mensajes de su bandeja de entrada.
R48. Los mensajes caducan transcurrido el periodo definido por el administrador.
R49. Se permitirá a usuarios registrados enviar mensajes a otros usuarios registrados.
R50. Los administradores podrán consultar y eliminar todos los correos enviados por la
aplicación.
El Sistema de Votaciones.
R51. El sistema de votaciones puede ser usado por compradores y vendedores.
R52. Un comprador puede votar a un vendedor al finalizar todo el proceso de pago y
recepción del producto.
R53. Un vendedor puede votar a un comprador al finalizar todo el proceso de cobro y
entrega del producto.
R54. Compradores y vendedores podrán consultar las votaciones pendientes.
El Sistema de Incidencias:
R55. Si algún comprador o vendedor tiene problemas durante una transacción (adquisición de un producto durante una compra o una subasta) podrá registrar dicho
problema en el sistema como una incidencia.
4.2. Elección de la Tecnologı́a
69
R56. Una incidencia es un mensaje enviado por el usuario que tiene el problema al
administrador.
R57. Un administrador puede enviar mensajes a otros usuarios.
El Sistema de Tareas Periódicas:
R58. El sistema tiene que realizar un resumen de las votaciones periódicamente, que
agrupe los datos por fecha desde, fecha hasta, usuario y categorı́a y que calcule el
valor medio.
R59. El sistema debe lanzar un proceso diariamente que compruebe si alguno de los
productos vendidos ha excedido el perı́odo denunciable, y en ese caso borrarlo
definitivamente de la base de datos.
R60. Cuando un producto sea eliminado de la base de datos, debe eliminarse también
toda la información asociada al mismo: transacciones, votaciones, etc.
R61. El sistema debe generar un informe periódicamente, resumiendo la información
de las tablas de datos de búsqueda de los usuarios, y enviarlo al administrador.
Una vez hecho esto borrará todos los datos recogidos hasta la fecha de generación
del informe.
R62. El sistema debe borrar los mensajes de los usuarios que hayan superado el tiempo
de caducidad de mensajes.
4.2.
Elección de la Tecnologı́a
Existe un amplio abanico de posibilidades a la hora de seleccionar una tecnologı́a para
desarrollar una aplicación web, pero para la implementación de la aplicación que aquı́ se
describe tendremos en cuenta los siguientes aspectos:
1. Debe permitir construir una aplicación multiplataforma de modo que pueda migrarse
fácilmente de unos sistemas a otros.
2. Debe disponer de un Entorno Integrado de Desarrollo (IDE) avanzado que ayude durante la construcción de la aplicación a base de ayuda contextual, refactorizaciones de
70
código, gestión de la compilación, control de versiones, editor de código fuente, debugger, generación de diagramas, etc.
3. En concreto, la tecnologı́a web empleada debe permitir construir una arquitectura basada en tres capas (persistencia, dominio y presentación) y la completa separación de
las tres capas.
Para abordar la fase de elección de la tecnologı́a con éxito es necesario pararse a pensar
qué tecnologı́as van a ser necesarias para la elaboración del proyecto:
1. ¿Qué Sistema Gestor de Bases de Datos se va a emplear?
2. ¿Cuál es el lenguaje de programación más adecuado?
3. ¿Cómo se va a gestionar la conexión a la base de datos?
4. ¿Qué framework nos da más flexibilidad a la hora de crear una aplicación web?
5. ¿Cuál es el entorno de desarrollo más adecuado?
6. ¿Qué programas usar para el diseño de la interfaz?
7. ¿Qué herramientas se van a utilizar para elaborar los diagramas y la documentación?
4.2.1.
Sistema Gestor de Base de Datos
Son muchos los Sistemas Gestores de Bases de Datos disponibles actualmente, pero se ha
optado por MySQL 5.0 debido a las siguiente razones [69]:
1. Está disponible para más de 20 plataformas incluyendo Linux, Windows, OS/X, HPUX, AIX, Netware, con lo que podemos considerar que permite construir aplicaciones
multiplataforma.
2. Dispone de clientes y administradores (MySQL query Browser y MySQL Administrator) que facilitan su uso, ası́ como el análisis de la base de datos que se pretende diseñar
con el objetivo de obtener el máximo rendimiento del SGBD.
3. Es Open Source, tiene gran rendimiento y confiabilidad, y es fácil de usar.
4.2.1.1.
71
Detalles de MySQL
Antes de construir la base de datos es necesario analizar en profundidad MySQL. Los
motores de almacenamiento de MySQL son los siguientes [67]:
1. MyISAM: es el motor de almacenamiento por defecto, no soporta tablas transaccionales, pero permite almacenar y recuperar los datos rápidamente, ası́ como búsquedas
fulltext.
2. MEMORY: proporciona tablas en memoria. No soporta tablas transaccionales.
3. MERGE: permite que una colección de tablas MyISAM idénticas sean tratadas como
una simple tabla.
4. InnoDB: permite tablas transaccionales, pero no soporta la búsqueda fulltext. Es el
único motor de MySQL que soporta claves ajenas [68].
5. EXAMPLE: permite crear tablas, pero no almacenar ni recuperar datos.
6. ARCHIVE: permite guardar grandes cantidades de datos sin ı́ndices con una huella
muy pequeña.
7. CSV: guarda datos en ficheros de texto usando formato de valores separados por comas.
De entre todos los motores citados anteriormente los más adecuados para la base de datos
de la aplicación son InnoDB y MyISAM. Aunque la mayor parte de las relaciones usarán el
motor InnoDB por las siguientes razones citadas en [67]:
Las tablas transaccionales (TSTs) tienen varias ventajas sobre las no transaccionales
(NTSTs)
1. Más seguras. Incluso si MySQL cae o tiene problemas de hardware, puede recuperar
los datos, mediante recuperación automática o desde una copia de seguridad más el
log de transacciones.
2. Puede combinar varios comandos y aceptarlos todos al mismo tiempo con el comando
COMMIT (si autocommit está desactivado).
72
3. Puede ejecutar ROLLBACK para ignorar los cambios (si autocommit está desactivado).
4. Si falla una actualización, todos los cambios se deshacen. (Con tablas no transaccionales, todos los cambios son permanentes) Motores de almacenamiento transaccionales
pueden proporcionar mejor concurrencia para tablas que tienen varias actualizaciones
concurrentes con lecturas.
Sin embargo, algunas tablas deberán ser implementadas con el motor MyISAM por moti-
vos de rendimiento, ya que según [3]:
Tablas no transaccionales tienen varias ventajas al no tener una sobrecarga transaccional:
1. Más rápidas.
2. Menor requerimiento de espacio.
3. Menos memoria para actualizaciones.
4.2.2.
Lenguaje de programación
Al igual que ocurre con las bases de datos, existe una gran cantidad de lenguajes de
programación. El elegido para la implementación del Proyecto es Java por los siguientes
motivos:
1. Es un lenguaje multiplataforma.
2. Es Open Source.
4.2.3.
Configuración de la conexión con la base de datos
Es importante definir cómo va a ser la conexión entre la base de datos y la aplicación web
por varios motivos:
73
La base de datos empleada es una base de datos Relacional, y el lenguaje de programación es un lenguaje orientado a objetos, con lo que debe hacerse un mapeo objetorelacional para hacer corresponder Relaciones y asociaciones de Relaciones con clases
Java.
Si alguna vez se desea cambiar de Base de Datos por cualquier motivo, y se ha pensado
en la configuración de la conexión con detenimiento, el cambio conllevará poco tiempo.
El mapeo Objeto-Relacional (ORM) [13] es la persistencia de objetos (ya sean de Java o
de cualquier otro lenguaje orientado a objetos) de manera automática y transparente en tablas
de una base de datos relacional, usando metadatos que describen las relaciones entre los objetos y la base de datos. Esta relación permite establecer una correspondencia bidireccional,
desde tablas a objetos y viceversa. Como consecuencia implica penalizaciones en el rendimiento. Sin embargo si ORM se implementa como un middleware, se pueden aplicar una
serie de optimizaciones que no serı́an posibles en un mapeo realizado a mano.
Una solución ORM está formada por cuatro aspectos:
Un API para realizar las operaciones CRUD básicas (Create, Read, Update, Delete)
sobre los objetos de clases persistentes.
Un lenguaje o API para especificar consultas que se refieren a clases y a propiedades
de clases.
Una facilidad para especificar los metadatos necesarios para el mapeo.
Una técnica que permita implementar ORM para interactuar con objetos transaccionales, realizar chequeos de objetos modificados durante la ejecución de la aplicación
(dirty checking), búsqueda perezosa de asociaciones, y otras funciones de optimización.
Con ORM la aplicación interactúa con los APIs del ORM y las clases del modelo de
dominio que se abstrae de los detalles de bajo nivel tales como SQL o JDBC. Dependiendo
de las caracterı́sticas de la implementación particular, el entorno de ejecución ORM puede
también tomar la responsabilidad de los asuntos tales como el bloqueo y cacheo optimista,
liberando a la aplicación por completo de estas cuestiones.
74
Hoy en dı́a existen muchos frameworks que facilitan la conexión con la Base de Datos y
que implementan ORM, en concreto para la aplicación se va a emplear Hibernate.
4.2.3.1.
Hibernate
Hibernate es una herramienta ORM que facilita el mapeo entre las relaciones de una base
de datos Relacional y los objetos del modelo de dominio de la aplicación en la que se pretende
integrar mediante ficheros XML.
Sus principales caracterı́sticas [85] [7] son las siguientes:
Da una solución al problema del Mapeo Objeto-Relacional (ya que los paradigmas de
Orientación a Objetos y Modelo Relacional son diferentes).
Usa ficheros XML para configurar los mapeos entre objetos y relaciones.
Las clases Java que se relacionan con las relaciones son los POJOs (Persistent Java
Objects).
Los POJOs son transformados a Relaciones y viceversa automáticamente por Hibernate. Hibernate genera las sentencias SQL y libera al desarrollador del manejo manual de
los datos que resultan de la ejecución de dichas sentencias, manteniendo la portabilidad
entre todos los motores de bases de datos con un ligero incremento en el tiempo de
ejecución.
Está diseñado para ser flexible en cuanto al esquema de tablas utilizado, para poder
adaptarse a su uso sobre una base de datos ya existente. También tiene la funcionalidad de crear la base de datos a partir de la información disponible (Permite tanto la
ingenierı́a directa como la inversa).
Dispone de un lenguaje de consulta HQL (Hibernate Query Language) de alto nivel,
independiente del motor de base de datos subyacente.
Procesamiento transparente sin procesamiento de byte code.
Generación automática de claves primarias.
75
HDLCA (Hibernate Dual-Layer Cache Architecture): hilos seguros, acceso a los datos no bloqueante, caché a nivel de sesión, caché de segundo nivel opcional, caché de
consultas opcional.
Alto rendimiento [7] (Lazy initialization, Outer join fetching, Batch fetching, Soporte para bloqueo optimista con versionado/timestamping, arquitectura altamente escalable, SQL generado en el tiempo de inicialización del sistema, pool de conexiones
interno opcional y caché de preparado de sentencias opcional).
4.2.4.
Tecnologı́a web empleada
Una vez fijado el lenguaje de programación, hay que seleccionar la tecnologı́a de desarrollo web adecuada en base a este.
Las tecnologı́as candidatas son JSP, Struts y JSF. JSP es la más antigua y primitiva, y las
otras dos son evoluciones de JSP. Se presenta una comparativa de las tres tecnologı́as en el
cuadro 4.1 [26].
Los asteriscos de la tabla indican que la tecnologı́a no soporta la caracterı́stica directamente pero que es posible conseguirla por medio de librerı́as de otras tecnologı́as.
Una vez evaluadas las caracterı́sticas de las tecnologı́as comparadas se comprueba que
JSF es una buena alternativa, ası́ que es la que se utiliza en el presente Proyecto.
4.2.4.1.
Java Server Faces (JSF)
Java Server Faces [64] es una Tecnologı́a de desarrollo Web que presenta tres caracterı́sticas importantes:
Dispone de un conjunto de controles gráficos de usuario (GUI Controls) y sus correspondientes manejadores.
Un marco de control de GUI independiente del dispositivo. JSF puede ser usado para
generar gráficos en formatos que no sean HTML y en protocolos que no sean HTTP.
Es una mejora de la Tecnologı́a Struts. Como Apache Struts, JSF puede ser visto como
76
Caracterı́stica
JSP Struts
JSF
Basado en el Modelo Vista Controlador
5
3
3
Facilidad para separar las capas de dominio y presentación
5
5
3
Controles GUI
5
5
3
Manejo de eventos
5
5
3
Beans gestionados
3
3
3
Lenguaje de expresión para acceder a las propiedades de los beans
3
3
3
Conversión y validación de campos de formulario
5
3
3
Configuración basada en un fichero centralizado
5
3
3
Facilidad de aprendizaje
3
3
5
Mucha documentación disponible
3
3
5
Mucha flexibilidad para configurar el aspecto
3
3
5
Acceso a los beans mediante un nombre asignado en la configuración
5
5
3
Lenguaje de Expresión muy potente
5
5
3
Definición de beans y controlador más simple
5
5
3
Uso de plantillas para reutilización de código (Tiles)
5
3
5*
Validación en cliente
3
3
5*
Soporte del método POST para formularios
3
3
3
Soporte del método GET para formularios
3
3
5
Soporte para internacionalización
5
3
3
Facilidad de uso de la internacionalización
5
5
3
Tabla 4.1: Comparativa de Tecnologı́as Web basadas en Java: JSP, Struts y JSF.
un Modelo Vista Controlador para construir formularios HTML, realizar las validaciones oportunas, invocar la lógica de negocio y mostrar los resultados.
En definitiva, JSF es una tecnologı́a de desarrollo Web basada en controles, de ahı́ que
podamos decir que intenta simular a las tı́picas tecnologı́as de desarrollo de aplicaciones de
escritorio con interfaces. Su flujo de trabajo el siguiente (ver figura 4.1):
1. Se muestra un formulario.
77
2. Se envı́a el formulario al servidor.
3. Se crea una instancia de un bean declarado en el fichero de configuración de JSF denominado (faces-config.xml).
4. Se invoca el método asociado al botón del formulario que provocó el envı́o del mismo
al servidor.
5. Se ejecuta el método e indica a qué pagina hay que ir.
6. Se muestra la página indicada por el método controlador.
Figura 4.1: Flujo de trabajo de JSF
El método de trabajo de JSF consta de varios pasos:
1. Crear un Bean.
a) Definir las propiedades para los datos del formulario.
b) Implementar los métodos controladores de la acción del formulario.
78
c) Definir las propiedades que actuarán como contenedores de resultados (placeholders).
2. Crear un formulario de entrada.
a) Los campos de entrada del formulario se corresponden con las propiedades del
Bean.
b) El botón especifica la condición de retorno (o el método controlador implementado en el Bean y asociado al botón).
3. Editar el fichero de configuración faces-config.xml (ver listing 4.1).
a) Declarar el Bean (sección managed-bean).
b) Especificar las reglas de navegación (sección navigation-rule).
4. Crear las páginas de resultados: salida de los datos del formulario de los resultados
producidos por la ejecución del método controlador tras el envı́o del formulario.
5. Prevenir el acceso directo a las páginas jsp (las .jsp): Usar un filtro que redireccione
pagina.jsp a pagina.jsf.
Listing 4.1: Aspecto del fichero de configuración de JSF (faces-config.xml)
<faces-config>
<managed-bean>
<managed-bean-name>BeanName</managed-bean-name>
<managed-bean-class>paquete.NombreClase</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
...
<navigation-rule>
<from-view-id>/pagina.jsp</from-view-id>
<navigation-case>
<from-outcome>outcome</from-outcome>
<to-view-id>/resultado.jsp</to-view-id>
</navigation-case>
79
...
</navigation-rule>
...
</faces-config>
Para comprender por completo tanto el flujo como el método de trabajo es necesario tener
claro qué es un Bean. Un Bean es una clase Java que sigue ciertas convenciones:
Debe tener un método constructor sin argumentos.
No debe tener propiedades o atributos con visibilidad pública.
Los valores persistentes deben ser accedidos mediante métodos denominados getXxx y
setXxx, donde Xxx es el nombre de la propiedad. Si se trata de una propiedad pública
los métodos para acceder a su valor son isXxx y getXxx.
Un Bean de JSF no necesita heredar de ninguna clase (en otras tecnologı́as como Struts
es necesario heredar de clases especiales).
4.2.4.2.
Servidor Web
Las aplicaciones que implementan JavaServer Faces [63] son compatibles con la especificación Servlet, en su versión 2.3 o superior, y con la especificación JavaServer Pages, en la
versión 1.2 o superior. Este requisito de la tecnologı́a seleccionada obliga a elegir un servidor
web que soporte Java Servlets [88] o bien instalar un paquete de servlets en el servidor web
deseado.
Para el Proyecto se ha optado por el servidor Apache Tomcat [74]. Tomcat is la implementación oficial de referencia de las especificaciones de servlets y JSP. Puede ser usado como
un pequeño servidor autónomo para testear servlets y páginas JSP o puede ser integrado en
un servidor Web Apache. Cuando se integra con Apache recibe el nombre de Apache Tomcat
y se caracteriza por:
Ser muy rápido.
Altamente confiable.
80
Difı́cil de configurar.
La versión de Apache Tomcat utilizada es la 6.0.16, una de las versiones más recientes.
4.2.5.
Entorno de desarrollo
Con el objetivo de facilitar en lo posible la tarea de programación es recomendable el uso
de un Entorno Integrado de Desarrollo (IDE). El entorno de desarrollo que se ha seleccionado
es Eclipse.
Eclipse es un entorno de desarrollo integrado de código abierto multiplataforma para desarrollar proyectos software. Existen muchas versiones de Eclipse, pero se ha seleccionado la
orientada a desarrollo web (Eclipse Ganymede JEE que es la versión 3.4 de Eclipse).
Las caracterı́sticas [84] que presenta son las siguientes:
Editor de texto.
Resaltado de sintaxis.
Compilación en tiempo real.
Pruebas unitarias con JUnit.
Control de versiones con CVS.
Integración con Ant.
Asistentes (wizards): para creación de proyectos, clases, tests, etc.
Refactorización.
Ayuda contextual.
Asimismo, a través de “plugins” disponibles es posible añadir:
• Control de versiones con Subversion.
• Integración con Hibernate.
• Soporte para facilitar el uso de otras tecnologı́as de desarrollo especı́ficas.
81
Aparte de las caracterı́sticas que presenta, se han añadido los plugins para Hibernate,
control de versiones con Subversion (SVN), para la creación de proyectos con Java Server
Faces (JSF) y para la integración con Apache Tomcat.
Se ha hecho uso de la tecnologı́a SVN con el objetivo de tener una copia en todo momento
del código fuente del Proyecto y ası́ evitar perder el Proyecto por posibles catástrofes como
rotura del disco duro, borrado de código de manera accidental, etc.
4.2.6.
Diseño de la interfaz
Antes de crear la interfaz es necesario realizar una serie de bocetos, seleccionar el más
adecuado y finalmente realizar la implementación. Para realizar los bocetos de la interfaz se
ha utilizado el editor de imágenes GIMP que es open source.
4.2.7.
Herramientas para la creación de los diagramas y documentación
Antes de ponerse a usar una herramienta para la generación de los diagramas y de la documentación conviene analizar qué herramientas (open source) están disponibles en el mercado,
y qué prestaciones nos ofrece cada una de ellas.
Tras hacer un estudio minucioso de dichas herramientas se ha decidido utilizar las siguientes por ser las más sencillas y a la vez las más completas de código abierto:
Jude Community: permite desarrollar los casos de uso, diagramas de secuencia, de clase
etc.
BrModelo: permite realizar el diagrama entidad/interrelación, el relacional y finalmente
obtener el código SQL basándose en el estándar SQL ANSI 2003. La transformación
del modelo conceptual al lógico está parcialmente automatizado.
Latex: para generar la documentación de este proyecto, ya que ofrece grandes ventajas
frente a otros editores.
Editor de imágenes Gimp: para el retoque y generación de imágenes.
Open office: para la creación de gráficos.
82
4.3.
Diseño de la base de datos
En esta sección se describe el desarrollo de la base de datos siguiendo la metodologı́a
propuesta en el capı́tulo anterior.
4.3.1.
Modelo Entidad Interrelación
En primer lugar se describen las Entidades extraı́das a partir de los requisitos del sistema
(ver diagrama en el apéndice A.1):
Producto: formado por el nombre, la descripción, el identificador, el nombre de la imagen, el precio de venta, el precio de subasta inicial, el precio de subasta actual, el número de pujadores y compradores, el tipo de mercado, la fecha de caducidad, la fecha de
registro y la disponibilidad.
Atributo: que consta de identificador, nombre, nombre del grupo al que pertenece, unidad de medida y un campo para indicar si el atributo pertenece o no al grupo principal.
Atributo Heredado: es una entidad usada para satisfacer el requisito de que los atributos
de una clase de productos puedan ser heredados por una clase de productos hija.
Valor de Publicación: consta de identificador, valor numérico y valor textual. Es usada
para almacenar una caracterı́stica de un producto como por ejemplo el color, etc.
Compra: formada por el identificador y la fecha en la que se realiza la compra.
Categorı́a: representa una clase de producto y tiene dos campos, el nombre y el identificador.
Subasta: almacena la información relativa a las subastas registradas en el portal. Está formada por un identificador, la fecha y hora de inicio, la fecha y hora de finalización, la
fecha de registro y un campo para indicar si la subasta ha sido asignada o aún está pendiente.
Usuario: es una entidad con los identificadores de los usuarios del sistema.
4.3. Diseño de la base de datos
83
Anónimo: subtipo de Usuario formado por dos campos (url referer) y la fecha de acceso.
Esta entidad es usada para obtener información sobre los usuarios que visitan el portal.
Usuario Registrado: subtipo de Usuario que mantiene la información de registro de
los usuarios de la aplicación. Consta de login, email, contraseña, teléfono, número de
identificación fiscal, dirección (que es un atributo compuesto por calle, código postal,
provincia, localidad y número), paı́s, número de activación y un campo para saber si la
cuenta está activa o no.
Empresa: es un subtipo de Usuario Registrado y consta de el nombre del logotipo de la
empresa, y el nombre comercial.
Particular: es un subtipo de Usuario Registrado y consta de primer apellido, segundo
apellido, y nombre.
Valor Jerarquı́a: es una entidad usada para tener los valores mı́nimos, máximos y medios
de un atributo asociado a una clase de producto. Dispone también de un identificador.
Tipo de Dato: mantiene la información de los tipos definidos en el sistema. Está formado por un nombre, una expresión regular que define a los tipos primitivos, un campo
lógico para determinar si el tipo tiene asociados valores finitos o no, un campo lógico
para determinar si el tipo es primitivo y un campo restricciones para los tipos derivados.
Denuncia: es la entidad que almacena las incidencias que registran los usuarios sobre
problemas durante la adquisición o entrega del producto. Consta de un identificador,
una descripción de la incidencia, el identificador del producto con el que está relacionado, el usuario que la registra y el usuario que la provoca.
Búsqueda: almacena información sobre las búsquedas de los usuarios que visitan el
portal. Consta de un identificador, un campo para indicar qué tipo de búsqueda se ha
realizado y la fecha en la que se realizó la búsqueda.
Valor de Búsqueda: es una entidad que almacena los requisitos de búsqueda de los usuarios en las búsquedas avanzadas (precisa y difusa). Está formada por un identificador,
84
un valor numérico, un valor textual y un campo para guardar la distancia difusa (para
el caso de las búsquedas difusas).
Perfil: guarda los perfiles que maneja la aplicación. Cada perfil tiene un identificador y
un nombre.
Provincia: consta de identificador y nombre.
Municipio: formado por un identificador, un código postal y un nombre.
Calle: que tiene un identificador, un nombre y un código postal.
Votación: entidad que almacena las votaciones de los usuarios. Una votación consta de
un identificador, de una valoración y de una fecha.
Mensaje: almacena los mensajes de los usuarios de la aplicación. Los atributos son
identificador, asunto, fecha, texto y campo lógico para indicar si el destinatario del
mensaje lo ha leı́do.
Resumen Mensual de Votaciones: entidad para resumir las votaciones en un intervalo
de tiempo. Se calcula la media de las votaciones en el periodo.
Adquisición: es el supertipo de las entidades Compra y Subasta.
Popuid: se usa para saber qué mensajes del administrador (que están en el servidor de
correos) han sido visualizados.
Parámetro: entidad para almacenar los parámetros de configuración de la aplicación.
Tiene un identificador, una descripción en castellano, un valor textual, un valor numérico, un nombre y una descripción en inglés.
Finalmente para comprender completamente el diagrama entidad interrelación es preciso
describir las interrelaciones. De cada interrelación es necesario indicar las cardinalidades y la
interpretación:
85
Pertenece(Categorı́a(1,1):Producto(0,n)): indica que una categorı́a tiene como máximo
n productos y que puede no tener ninguno, y que un producto pertenece a una sola
categorı́a.
Incluye(Compra(0,1):Producto(1,1)): una compra incluye uno y solo un producto, y
que un producto puede o no estar incluido en una compra.
FormadoPor(Producto(1,1):Valor de Publicación(0,n)): un producto puede no tener valores de publicación o bien puede tener n. Un valor de publicación está asociado a uno
y solo un producto.
Incluye2(Producto(1,1):Subasta(0,1)): un producto puede estar o no incluido en una
subasta. Una subasta se refiere a un único producto.
Puja(Producto(0,n):Usuario Registrado(1,1)): un usuario no puja o puja por n productos. En una puja interviene un usuario registrado. La puja tiene un identificador, una
fecha y una cuantı́a.
Vende(Producto(0,n), Usuario Registrado(1,1)): un usuario registrado vende n productos como máximo. Un producto es vendido por uno y sólo un usuario registrado. La
venta se produce en una fecha, tiene un identificador y una fecha de caducidad.
EsPadreDe(Categorı́a(1,1):Categorı́a(0:n)): una categorı́a (padre) no tiene subcategorı́as
o tiene hasta n. Una categorı́a (hija) tiene una y solo una categorı́a padre.
Tiene(Categorı́a(1,1):Atributo(1,n))): Una categorı́a tiene entre 1 y n atributos, y un
atributo pertenece a una y solo una categorı́a.
Pertenece(Valor de Jerarquı́a(0,n):Atributo(1,1)): un atributo tiene o ninguno o n valores de jerarquı́a. Un valor de Jerarquı́a está asociado a uno y solo un atributo.
EsValoradoCon(Atributo(1,1):Valor de Publicación(0,n)): un atributo puede tener asociados ningún valor de publicación o como mucho n. Un valor de publicación está asociado a uno y sólo un atributo.
86
AsociadoA(TipoDato(1,1):Atributo(1,1)): un atributo está asociado a un único tipo de
datos y viceversa.
Tiene(Atributo Heredado(0,n):Categorı́a(1,1)): una categorı́a o no tiene atributos heredados o tiene como máximo n, y un atributo heredado pertenece a una y solo una
categorı́a.
EsUn(Atributo heredado(0,1),Atributo(1,1)): un atributo heredado es un atributo y un
atributo puede ser o no atributo heredado.
Realiza(Compra(0,n):Usuario Registrado(1,1)): un usuario registrado puede realizar
como máximo n compras. Una compra es realizada por un usuario registrado.
Adjudicar(Subasta(0,n):Usuario Registrado(1,1)): un usuario registrado puede realizar
varias subastas. Una subasta solo puede ser registrada en el sistema por un usuario
registrado.
EsAdjudicada(Subasta(1,1):Usuario Registrado(1,1)): una subasta es adjudicada a uno
y solo un usuario Registrado.
Recibe(Usuario Registrado(1,1):Denuncia(0,n)): un usuario registrado puede recibir
varias denuncias. Una denuncia va dirigida a un usuario registrado.
Tramita(Usuario Registrado(1,1):Denuncia(0,n)): un usuario registrado puede tramitar
hasta n denuncias. Una denuncia solo puede ser tramitada por un único usuario registrado.
AsociadaA(Compra(1,1):Denuncia(0,1)): una compra puede tener asociada una o denuncia o ninguna. Una denuncia está asociada a una compra.
RealizadaPor 2(ValorBusqueda(1,n):Usuario(1:1)): una valoración de búsqueda es realizada un usuario. Un usuario especifica uno o varios valores de búsqueda.
SeCompone(ValorBusqueda(1,n):Búsqueda(1,1)): una búsqueda se compone de 1 o n
valores de búsqueda. Un valor de búsqueda perteneces a una y solo una búsqueda.
87
AsociadaA(Búsqueda(1,n),Categorı́a(1,1)): Una búsqueda está asociada a una categorı́a.
Una categorı́a tiene varias búsquedas asociadas.
Tiene(Calle(1,n):Municipio(0,n)): Un municipio tiene varias calles. Una calle pertenece
a un municipio.
Tiene(Provincia(1,1):Municipio(1,n)): Una provincia tiene varios municipios. Un municipio pertenece a una provincia.
Vota(UsuarioRegistrado(1,1):Votación(0,n)): Un usuario registrado realiza un máximo
de n votaciones. Una votación pertenece a uno y solo un usuario registrado.
EsVotado(Votación(0,n):UsuarioRegistrado(1,1)): Un usuario registrado es votado en
una votación hasta n veces. Una votación es asignada a uno y solo un usuario registrado.
Envı́a(UsuarioRegistrado(0,n):Mensaje(0,n)): un usuario registrado puede enviar hasta
n mensajes. Un mensaje es enviado por uno y sólo un usuario registrado.
EsRecibido(UsuarioRegistrado(1,1):Mensaje(0,n)): Un usuario registrado recibe hasta
n mensajes. Un mensaje es recibido por uno y solo un usuario registrado.
Asociada2(Categorı́a(1,1):ResumenMensualVotaciones(1,1)): Una categorı́a está asociada a un resumen de votaciones. Un resumen de votaciones está asociado a una categorı́a.
RelativaA(ResumenMensualVotaciones(1,n):UsuarioRegistrado(1,1)): un resumen de
votaciones está asociado a un usuario registrado. Un usuario registrado tiene asociados hasta n resúmenes de votaciones.
AsociadaA(Votación(1,n):Categorı́a(1,1)): Una votación está asociada a una categorı́a.
A una categorı́a están asociadas hasta n votaciones.
AsociadaA(Votación(0,2):Adquisición(1,1)): Una votación está asociada a una y solo
una adquisición (compra o subasta). A una adquisición se asocian como máximo dos
votaciones.
88
AsociadaCon(Empresa(0,n):Categorı́a(1,n)): Una empresa está asociada con un máximo de n empresas. A una categorı́a están asociadas hasta n empresas.
Tiene(UsuarioRegistrado(1,n):Perfil(1,n)): Un usuario registrado puede tener varios perfiles asociados. Un perfil puede estar asociado a varios usuarios registrados.
EsValoradoCon 2(Atributo(1,1):ValorBusqueda(0,n)): un atributo es valorado con un
máximo de n valores de búsqueda. Un valor de búsqueda valora a uno y solo un atributo.
Deriva(TipoDato(1,1): TipoDato(1,n)): un tipo de dato primitivo deriva en n tipos de
datos derivados. Un tipo de dato derivado deriva de uno y solo un tipo de dato primitivo.
4.3.2.
Modelo Relacional
A partir del diagrama entidad Interrelación construido en el apartado anterior, se obtiene
el diagrama relacional aplicando las reglas de transformación comentadas en 3.2.2.
Tras aplicar dichas reglas se han obtenido las siguientes relaciones (ver diagrama en el
apéndice A.2):
Votación: almacena todas las votaciones que realizan los usuarios registrados.
Categorı́a: almacena todas las clases de productos registradas en el portal.
Categorı́a Empresa: en esta relación responde a la pregunta en qué categorı́as tiene
productos una empresa.
Compra: contiene todas las compras del mercado de venta directa.
Subasta: contiene todas las subastas (del mercado de subastas) registradas en el portal.
Valor Publicación: es la relación que mantiene todas las propiedades de los productos
registrados en el portal. Ej. color, peso, etc.
Atributo: contiene cada una de las caracterı́sticas asociadas a una cierta clase de productos. Ej. el color, el peso, etc.
89
Atributo Heredado: es la relación que contesta a la pregunta qué atributos se han heredado de una clase C en una clase C1, siendo C1 hija de C.
Producto: almacena la información básica de cada uno de los productos almacenados
en la base de datos. Se trata de la información básica, porque la información detallada
se encuentra en la relación Valor Publicación.
Venta: todas las ventas (del mercado de venta directa) registradas en el portal.
Tipo Dato: contiene todos los tipos de dato del portal (primitivos y derivados).
Valor Jerarquı́a: relación (añadida por cuestiones que se verán más adelante) que almacena información sobre los atributos de una clase de productos, en concreto los mı́nimos, los máximos y los valores medios (de atributos numéricos).
Búsqueda: relación que mantiene todas las búsquedas realizadas por los usuarios del
portal.
Valor Búsqueda: contiene las valoraciones de los distintos atributos de una clase de
productos, durante la búsqueda realizada por un usuario.
Usuario Registrado: almacena la información sobre los usuarios registrados en el portal.
Resumen Votaciones: contiene todos los resúmenes de las votaciones asignadas a los
usuarios registrados agrupadas por periodos de tiempo, categorı́a y usuario.
Empresa: almacena los datos relativos al registro de una empresa.
Perfil: contiene todos los perfiles de la aplicación.
Perfil Usuario: responde a la pregunta ¿qué perfiles tienen asociados cada uno de los
usuarios del portal?
Mensaje: contiene todos los mensajes enviados por los usuarios del portal.
Particular: almacena la información relativa al registro de particulares.
Puja: es la relación que guarda todas las pujas relativas a las subastas del portal.
90
Usuario: contiene todos los usuarios del portal.
Denuncia: contiene todas las incidencias de los usuarios.
Anónimo: sirve para extraer información sobre los usuarios anónimos que visitan el
portal.
Parámetro: es una relación especial (ya que no tiene relaciones con otras tablas de la
base de datos) debido a que se usa para configurar parámetros que afectan al comportamiento de la aplicación.
Popuid: es una relación especial que sirve únicamente para la lectura de correos del
servidor de correos y distinguir cuáles han sido leı́dos y cuáles no, ya que el protocolo
POP3 desconoce esta información.
Provincia.
Municipio.
Calle.
Una vez que ya sabemos cuáles son las relaciones de la base de datos es necesario saber
qué asociaciones existen entre ellas:
Categorı́a → Categorı́a: existe una clave ajena que parte de la relación Categorı́a con
destino en la relación Categorı́a, usada para crear un árbol de clases de producto, y
ası́ saber qué clase es padre de otra clase.
Categorı́a Empresa → Categorı́a.
Categorı́a Empresa → Empresa. Estas dos últimas asociaciones establecen qué empresas se asocian con qué categorı́as y viceversa.
Votación → Usuario Registrado (2 relaciones): Votación tiene dos asociaciones con
Usuario Registrado, que establecen quién es el usuario votante y el votado.
Votación → Categorı́a: cada votación es relativa a una categorı́a.
91
Votación → Compra (opcional): una votación puede estar asociada a una compra.
Votación → Subasta (opcional): una votación puede estar asociada a una subasta.
Compra → Usuario Registrado: identifica al usuario registrado que compra el producto.
Compra → Producto: permite saber a qué producto se asocia la compra.
Subasta → Usuario Registrado (2 relaciones): una establece quién es el propietario del
producto subastado y la otra quién es el ganador de la subasta.
Subasta → Producto: asocia la subasta con un producto.
Atributo Heredado → Categorı́a.
Atributo Heredado → Atributo. Estas dos últimas interrelaciones sirven para indicar
qué atributo se ha heredado en una determinada categorı́a.
Valor Publicación → Producto.
Valor Publicación → Atributo. Estas asociaciones que parten de Valor Publicación permiten identificar el producto al que pertenece la valoración de un cierto atributo de una
clase.
Atributo → Tipo Dato: asocia un atributo con un tipo de datos.
Atributo → Categorı́a: asocia un atributo con una clase de producto.
Producto → Categorı́a: asocia un producto con su clase de producto.
Tipo Dato → Tipo Dato: asocia un tipo de dato derivado con su tipo de dato primitivo.
Valor Jerarquı́a → Atributo: permite calcular los valores mı́nimo, máximo y medio de
cada uno de los atributos de una clase de productos (incluidos los heredados).
Valor Búsqueda → Atributo.
Valor Búsqueda → Búsqueda: asocia una valoración de búsqueda con una búsqueda y
con el atributo al que se refiere.
92
Venta → Usuario Registrado: permite identificar el usuario que vende el producto.
Venta → Producto: permite identificar el producto al que se refiere la venta.
Búsqueda → Usuario Registrado: establece qué usuario realiza la búsqueda.
Búsqueda → Categorı́a: identifica la categorı́a a la que se refiere la búsqueda.
Usuario Registrado → Usuario.
Resumen Votaciones → Categorı́a: asocia un resumen de votaciones con una categorı́a.
Resumen Votaciones → Usuario Registrado: permite identificar al usuario al que se
refiere un resumen de votaciones.
Empresa → Usuario Registrado: permite distinguir qué usuarios registrados son empresas. Es necesario porque los identificadores de usuario (logins) deben ser únicos en
el sistema.
Particular → Usuario Registrado: permite distinguir qué usuarios registrados son particulares.
Mensaje → Usuario Registrado (2 relaciones): una identifica al usuario emisor y la otra
al receptor del mensaje.
Perfil Usuario → Perfil.
Perfil Usuario → Usuario Registrado: estas dos últimas interrelaciones permiten saber
de qué perfiles disponen los usuarios del sistema.
Puja → Usuario Registrado: identifica al usuario registrado que realiza la puja.
Puja → Producto: identifica el producto al que se refiere la puja.
Denuncia → Usuario Registrado (2 relaciones): identifica a los usuarios registrados que
juegan el papel de denunciante y denunciado.
Denuncia → Compra (opcional): identifica la compra (en el mercado de venta directa)
a la que se refiere la denuncia.
93
Denuncia → Subasta (opcional): identifica la subasta (en el mercado de subastas) a la
que se refiere la denuncia.
Anónimo → Usuario: permite identificar cuáles son los usuarios anónimos de entre
todos los usuarios del portal. Cuando un usuario visita el portal, la aplicación asigna un
identificador de sesión al usuario, identificándolo como un usuario anónimo.
Municipio → Provincia: permite asociar cada municipio con su provincia.
Calle → Municipio: asocia cada calle con su provincia.
En el diagrama (ver apéndice A.2) pueden verse todas las relaciones junto con sus asociaciones. Para interpretarlo correctamente, es necesario saber que los iconos con forma de llave,
de color amarillo, representan las claves primarias de las relaciones, y que las de color gris,
las claves ajenas. Las lı́neas se corresponden con las asociaciones explicadas anteriormente.
4.3.3.
Modelo fı́sico
Una vez completado el diagrama relacional se obtiene el modelo fı́sico de la base de
datos. Para ello, previamente es necesario seleccionar el motor de base de datos a utilizar. Se
ha seleccionado MySQL.
A partir del diagrama relacional, se extrae el código SQL propio de MySQL para crear la
base de datos en MySQL. Antes de crear la base de datos es necesario estudiar los procesos a
los que van a ser sometidas cada una de las tablas o relaciones de la aplicación con el objetivo
de obtener el máximo rendimiento de la base de datos.
MySQL dispone, entre otros, de dos tipos de relaciones esenciales, las MyISAM y las
InnoDB. Las InnoDB permiten claves ajenas, y como consecuencia de esto, una gran ahorro
de trabajo para el programador a la hora de eliminar elementos de una tabla referenciada, ya
que se puede indicar mediante restricciones al SGBD.
Estas restricciones van asociadas a la clave ajena y pueden ser ejecutadas al borrar y al
actualizar (ON DELETE, ON UPDATE). Las que se han usado con más frecuencia en la
base de datos de la aplicación (ver listado 4.2) son las de borrado (ON DELETE). Con estas
restricciones, al eliminar una de las filas referenciadas (tabla a la que apunta la clave ajena), se
94
borran las que referencian a la misma. No sólo supone un ahorro de trabajo, si no que también
supone un modelo más cercano al relacional, y por tanto más consistente y coherente con el
mismo.
Listing 4.2: Algunas restricciones de clave ajena de la aplicación
...
ALTER TABLE ValorBusqueda ADD FOREIGN KEY(Atributo)
REFERENCES Atributo (IdAtributo) ON UPDATE CASCADE
ON DELETE CASCADE;
ALTER TABLE ValorBusqueda ADD FOREIGN KEY(Busqueda)
REFERENCES Busqueda (IdBusqueda) ON UPDATE CASCADE
ON DELETE CASCADE;
ALTER TABLE TipoDato ADD FOREIGN KEY(Supertipo)
REFERENCES TipoDato (Nombre) ON UPDATE CASCADE
ON DELETE CASCADE;
...
Por su parte las MyISAM no permiten claves ajenas, pero permiten consultas Full Text
[65]. Una consulta Full Text es una consulta de búsqueda de texto en registros de la base de
datos que proporciona un gran rendimiento y que puede devolver los registros encontrados
ordenados de mayor a menor relevancia. Como con conclusión, la mayor parte de las tablas
de la base de datos serán del tipo InnoDB, excepto aquellas sobre las que se requiera lanzar
una gran cantidad de consultas de búsqueda. En la tablas 4.2 y 4.3 se muestra la asignación
de los tipos de relación para cada una de las tablas de la aplicación.
Se observa que casi todas las relaciones son InnoDB a excepción de Producto, y Popuid,
que requieren una gran cantidad de consultas.
Se necesita que la aplicación borre los productos caducados y toda la información relativa
a los mismos, ası́ como que este proceso sea automático para liberar a núcleo de la aplicación
de una carga que deberı́a ser de la base de datos. Como se ha mencionado anteriormente
MyISAM no lo permite, por lo que hay que buscar una solución alternativa.
Relación o tabla
95
tipo
¿Sometida a muchas búsquedas?
Anónimo
InnoDB
5
Atributo
InnoDB
5
Atributo Heredado
InnoDB
5
Búsqueda
InnoDB
5
Calle
InnoDB
5
Categorı́a
InnoDB
5
Categorı́a Empresa
InnoDB
5
Compra
InnoDB
5
Denuncia
InnoDB
5
Empresa
InnoDB
5
Mensaje
InnoDB
5
Municipio
InnoDB
5
MyISAM
3
InnoDB
5
Popuid
Parámetro
Tabla 4.2: Asignación de motores de MySQL a las relaciones de la aplicación (parte I).
4.3.3.1.
Solución al problema de las tablas MyISAM
Con objeto de simular las restricciones de clave ajena ON DELETE y ON UPDATE [66],
para la tabla Producto, se han utilizado disparadores.
Listing 4.3: Tabla adicional para controlar la restricción de clave ajena mediante disparadores
CREATE TABLE error_msg (error_msg VARCHAR(32) NOT NULL PRIMARY KEY);
INSERT INTO error_msg VALUES (’Foreign Key Constraint Violated!’);
En el listado 4.4 puede observarse uno de los varios disparadores que controlan las restricciones de clave ajena al realizar un insert sobre una tabla (en el ejemplo sobre la tabla
Compra) que comprueba que al insertar en una tabla y hacer referencia a una tabla padre, en
la tabla padre existe realmente el elemento al que se hace referencia. Esta técnica requiere
que en la base de datos se cree una tabla con una fila que contenga el mensaje de error de la
violación de clave ajena (ver listado 4.3).
96
Relación o tabla
tipo
¿Sometida a muchas búsquedas?
Particular
InnoDB
5
Perfil
InnoDB
5
Perfil Usuario
InnoDB
5
Producto
MyISAM
3
Provincia
InnoDB
5
Puja
InnoDB
5
Resumen Votaciones
InnoDB
5
Subasta
InnoDB
5
Tipo Dato
InnoDB
5
Usuario
InnoDB
5
Usuario Registrado
InnoDB
5
Valor Búsqueda
InnoDB
5
Valor Jerarquı́a
InnoDB
5
Valor Publicación
InnoDB
5
Venta
InnoDB
5
Votación
InnoDB
5
Tabla 4.3: Asignación de motores de MySQL a las relaciones de la aplicación (parte II).
También es necesario definir los disparadores que controlan la restricción de clave ajena
al actualizar una tabla (ver listado 4.5).
Listing 4.4: Restricción de clave ajena mediante disparadores (al insertar)
CREATE TRIGGER FKI_Compra_Producto
BEFORE INSERT
ON Compra
FOR EACH ROW
BEGIN
IF (SELECT COUNT(*) FROM Producto WHERE IdProducto=new.Producto)=0
THEN
INSERT error_msg VALUES (’Foreign Key Constraint Violated!’);
END IF;
97
END;
Listing 4.5: Restricción de clave ajena mediante disparadores (al actualizar)
CREATE TRIGGER Update_Compra
AFTER UPDATE
ON Compra
FOR EACH ROW
BEGIN
IF (SELECT COUNT(*) FROM Producto WHERE IdProducto=new.Producto)=0
THEN
END IF;
END;
Finalmente se han creado disparadores para simular las restricciones de clave ajena ON
DELETE CASCADE y ON UPDATE CASCADE (ver listado 4.6).
Listing 4.6: Restricciones on delete cascade y on update cascade
CREATE TRIGGER OnDeleteCascade_CVVPS
BEFORE DELETE
ON Producto
FOR EACH ROW
BEGIN
DELETE FROM Compra WHERE Producto=old.IdProducto;
DELETE FROM Venta WHERE Producto=old.IdProducto;
DELETE FROM ValorPublicacion WHERE Producto=old.IdProducto;
DELETE FROM Puja WHERE Producto=old.IdProducto;
DELETE FROM Subasta WHERE Producto=old.IdProducto;
END;
CREATE TRIGGER OnUpdateCascade_CVVPS
AFTER UPDATE
ON Producto
FOR EACH ROW
BEGIN
UPDATE Compra SET Producto=new.IdProducto
WHERE Producto=old.IdProducto;
98
UPDATE Venta SET Producto=new.IdProducto
UPDATE ValorPublicacion SET Producto=new.IdProducto
UPDATE Puja SET Producto=new.IdProducto
UPDATE Subasta SET Producto=new.IdProducto
-- comprobamos que producto apunta a alguna categoria
IF (SELECT COUNT(*) FROM Categoria
WHERE IdCategoria=new.Categoria)=0
THEN
END IF;
END;
4.3.3.2.
Buscando la eficiencia
Finalmente con objeto de cumplir los requisitos de eficiencia de la aplicación (requisitos
no funcionales) se ha añadido redundancia y campos resumen a las relaciones de la base de
datos.
Por ejemplo, la tabla Producto tiene los campos precio, precio de subasta y otros campos
que están definidos en el catálogo del producto, pero que con objeto de acceder más rápidamente a esta información se han redefinido en la tabla citada.
La tabla Valor Jerarquı́a es una tabla resumen que contiene los datos precalculados de
los atributos numéricos del catálogo de productos, permitiendo de esta manera que los datos
estén disponibles cuando se necesitan y no haya que calcularlos dinámicamente cada vez que
son necesarios (media, máximos y mı́nimos).
Además de añadir redundancia se han analizado las sentencias que el Sistema Gestor de
Base de Datos tiene que ejecutar, con objeto de optimizarlas y que presenten tiempos de
respuesta adecuados.
Además de optimizar las consultas se han creado ı́ndices de ordenación en las tablas de
las base de datos. Estos ı́ndices aceleran notablemente las consultas.
99
En la figura 4.2 se comparan los tiempos de respuesta frente al número de atributos con
distinto número de registro en la tabla producto. Se observa que el número de atributos consultados no parece influir en la consulta, pero que el número de registros de la tabla Producto
si que afecta bastante, a mayor número de registros mayor tiempo de respuesta.
Figura 4.2: Comparativa no registros - no atributos - tiempo (s) (parte I)
En la figura 4.3 se vuelve a comprobar que a mayor carga mayor tiempo de respuesta.
También se observan tiempos de respuesta poco adecuados (más de un minuto). Además, si
se sigue aumentando el número de registros las consultas van haciéndose cada vez más lentas
hasta el punto de tardar más de una hora.
Como los tiempos de respuesta no son adecuados para la construcción de un portal Web,
se optimiza añadiendo ı́ndices que aceleren la búsqueda. En la figura 4.4 se observa que los
tiempos disminuyen, pero siguen siendo inapropiados.
Finalmente se optimizan las consultas. En algunas ocasiones la optimización solo puede
ser viable si se descarta la consulta con la que se venı́a trabajando. Tras aplicar una serie de
optimizaciones a la consulta (eliminar el operador lógico in, utilizar únicamente productos
cartesianos y agrupamientos) se obtiene una consulta que arroja muy buenos resultados, los
100
Figura 4.3: Comparativa no registros - no atributos - tiempo (s) (parte II)
tiempos de respuesta no superan en ningún caso los tres segundos y medio (ver figura 4.5),
unos tiempos muy adecuados para un portal Web.
En definitiva se han obtenido consultas muy optimizadas, recuérdese que con las primeras
consultas se obtenı́an tiempos superiores a la hora y finalmente se han obtenido tiempos
inferiores a los 4 segundos.
4.4.
Aplicación del Proceso Unificado
En esta sección se va a describir cómo se ha aplicado el Proceso Unificado al presente Proyecto Fin de Carrera. Se comenzará describiendo el plan de iteraciones para posteriormente
pasar a describir algunos casos de uso (los más importantes).
4.4.1.
Plan de iteraciones
Una vez que ya están claros los requisitos (ver catálogo de requisitos, sección 4.1) se
elabora el plan de iteraciones, que va a estar formado por tres fases:
Fase de iniciación: en ella se establecen los objetivos del proyecto y se identifican los
casos de uso que se desprenden de los requisitos del sistema. Es necesario tener en
4.4. Aplicación del Proceso Unificado
101
Figura 4.4: Tiempos de respuesta con ı́ndices
cuenta tanto requisitos funcionales como no funcionales.
Fase de elaboración: durante esta fase se construye el núcleo central de la arquitectura.
Fase de construcción: en esta fase se termina de elaborar todo el proyecto.
4.4.1.1. Fase de iniciación: Iteración 0
El principal objetivo del proyecto es construir una aplicación de comercio electrónico que:
Facilite la gestión de las clases de producto manejadas en el portal, permitiendo la
creación, modificación y borrado de clases de producto.
Facilite la localización de productos a los usuarios. Para ello debe ofrecer buenos buscadores y permitir realizar búsquedas de varias formas: mediante texto, mediante clases
de producto, combinación de las anteriores, mediante especificación de caracterı́sticas
precisas y mediante la especificación de caracterı́sticas de manera imprecisa o con incertidumbre.
Facilite el registro de productos y la gestión de la información asociada a cada uno de
ellos.
102
Figura 4.5: Tiempos de respuesta de la consulta optimizada
Permita a los compradores adquirir los productos anunciados en el mismo.
Permita vender y subastar productos.
Ponga en contacto a vendedores y compradores.
Gestione usuarios (alta, baja y modificación de los datos de los usuarios registrados).
Disponga de una arquitectura escalable, con vistas a integrarlo en un sistema multiagente, que en un futuro, permita liberar al comprador de productos subastados, de
estar pegado al ordenador para pujar por un producto.
Informe al administrador del estado del portal en todo momento mediante gráficos.
Permita notificar incidencias a compradores y vendedores.
Ponga en contacto a particulares y a empresas, o bien a empresas de modo que no
sólo sea un portal de comercio electrónico de consumidor a consumidor, si no entre
empresas y consumidores, entre empresas o bien entre particulares y empresas.
Permita buscar productos de una empresa.
Permita localizar las empresas registradas en el portal.
103
Ahora que ya están definidos los principales objetivos del proyecto se identifican los principales casos de uso de la aplicación agrupados por funcionalidades (ver los diagramas del
anexo B.1.1):
Sistema de Búsqueda.
• Buscar productos.
• Buscar Productos mediante el modo por defecto.
• Buscar Productos utilizando el método Texto-Categorı́a.
• Buscar utilizando el método Texto.
• Buscar utilizando el método de exploración de categorı́as.
• Buscar productos mediante el modo avanzado.
• Buscar utilizando el método Caracterı́sticas Precisas.
• Buscar utilizando el método Caracterı́sticas Difusas.
• Buscar Productos del mercado de venta directa.
• Buscar Productos del mercado de subastas.
• Ordenar resultados de búsqueda.
• Guardar entrada del usuario
Sistema de Configuración de Parámetros.
• Configurar parámetros
Sistema de Gestión de Clases de Producto.
• Gestión de clases de producto.
• Modificar clase de producto.
• Crear clase de producto.
• Añadir atributos de clase.
• Eliminar clase de producto.
104
• Eliminar atributos de clase.
• Actualizar productos asociados a una clase de producto modificada.
• Eliminar Valoraciones de productos asociadas a los atributos.
• Informar del cambio a los dueños del producto.
Sistema de Gestión de Cuentas.
• Crear Cuenta para Registrarse.
• Crear Cuenta Particular.
• Crear Cuenta Empresa.
• Modificar Cuenta.
• Modificar Cuenta Particular.
• Modificar Cuenta Empresa.
• Eliminar Cuenta.
• Eliminar productos asociados a la cuenta.
Sistema de Identificación.
• Identificarse en el sistema.
Sistema de Gestión de Mensajes.
• Consultar Mensajes Recibidos.
• Borrar Mensajes Recibidos.
Sistema de Adquisición de Productos.
• Comprar producto.
• Buscar Productos.
• Enviar mensaje.
• Pujar por un producto.
105
Sistema de Registro de Productos.
• Registrar Producto en el portal.
• Registrar Producto para Venta Directa.
• Registrar Producto para Venta directa y para Subasta.
• Registrar Producto para subasta.
Sistema de Gestión de Tipos.
• Gestión de tipos derivados.
• Modificar tipo de dato derivado.
• Crear tipo de dato derivado.
• Eliminar tipo de dato derivado.
• Informar del cambio a los dueños del producto.
• Consultar tipos primitivos.
• Eliminar Atributos dependientes del Tipo Derivado.
• Eliminar Valoraciones asociadas al atributo.
4.4.1.2.
Fase de iniciación: Iteración 1
Durante los primeros pasos del Proyecto tuvieron lugar varias reuniones en las que se
extrajeron más requisitos (ver anexo C). Muchos de ellos han sido desarrollados y otros se
han desechado por razones de tiempo o bien por no ser viables.
Durante esta iteración se realiza el análisis de los requisitos no tratados en la iteración
anterior y de los nuevos requisitos añadidos durante las reuniones.
Los casos de uso identificados en esta iteración son los siguientes (ver los diagramas del
anexo B.1.2):
Sistema de Búsqueda (búsqueda de Empresas).
• Buscar Empresas por categorı́as.
106
• Consultar productos asociados a la empresa y a la categorı́a.
• Ordenar Empresas en base a la valoración en la categorı́a.
• Buscar Empresas por nombre.
Sistema de Búsqueda (Consulta de Productos).
• Listar Categorı́as.
• Listar Productos asociados a una categorı́a.
Sistema de Búsqueda (Difusa).
• Buscar utilizando el método Caracterı́sticas Difusas.
• Lectura y validación de distancias según el Tipo de dato.
• Búsqueda de Productos en base a las distancias.
• Configuración del interfaz para asignar las distancias.
Sistema de Gestión de Cuentas.
• Crear Cuenta de Administrador.
• Solicitar sugerencia de localización.
• Listar usuarios registrados.
• Activar cuenta.
• Recuperar contraseña.
• Listar los productos registrados de un usuario.
Sistema de Gestión de Productos.
• Consultar caracterı́sticas de un producto.
• Carga masiva de Productos vı́a XML.
Sistema de Incidencias.
• Registrar incidencia.
107
• Listar incidencias.
• Eliminar incidencias.
Sistema de Mensajes.
• Enviar mensaje a otro usuario.
• Consultar mensajes enviados.
Sistema de Tareas Periódicas.
• Borrar Mensajes caducados.
• Listar informes generados por la aplicación.
• Generar informe de búsqueda.
• Borrar búsquedas asociadas al informe.
• Eliminar transacciones de compra y subasta caducadas.
• Eliminar productos asociados a dichas transacciones.
• Eliminar toda la información relativa a los productos borrados.
• Resumir votaciones periódicamente, por usuario, calculando la media de las votaciones individuales.
• Borrar votaciones resumidas.
• Eliminar informes.
• Enviar informes a la cuenta de correo electrónico de la aplicación.
Sistema de Votaciones.
• Votar a comprador.
• Consultar votaciones pendientes.
• Votar a vendedor.
• Listar valoraciones de un usuario por categorı́a.
• Listar el número de votaciones pendientes de un usuario por categorı́a.
108
Sistema de adquisición de productos.
• Informar al usuario ganador de la subasta al finalizar.
• Recuperar subastas tras una parada en la aplicación (caı́da del servidor por algún
error en tiempo de ejecución).
• Listar productos comprados, ganados en subasta, y aquellos por los que se haya
pujado y no hayan sido adquiridos.
• Generar gráfica de evolución de pujas.
Sistema de correos (emails).
• Consultar correos enviados a la cuenta de correo de la aplicación.
• Borrar correos enviados a la aplicación.
• Filtrar correos enviados a la aplicación por leı́dos / no leı́dos.
4.4.1.3. Fase de iniciación: Iteración 2
En esta iteración ya se dispone de todos los casos de uso de la aplicación. Ahora interesa
establecer el orden en que se van a construir. Por ello se crea lo que el Proceso Unificado
denomina priorización de casos de uso:
1. Listar Categorı́as.
2. Listar Productos asociados a una categorı́a.
3. Buscar Productos mediante el modo por defecto.
4. Buscar Productos utilizando el método Texto-Categorı́a.
5. Buscar utilizando el método Texto.
6. Buscar utilizando el método de exploración de categorı́as.
7. Buscar productos mediante el modo avanzado.
8. Buscar utilizando el método Caracterı́sticas Precisas.
9. Buscar utilizando el método Caracterı́sticas Difusas.
10. Buscar Productos del mercado de venta directa.
11. Buscar Productos del mercado de subastas.
12. Ordenar resultados de búsqueda.
13. Consultar caracterı́sticas de un producto.
14. Buscar utilizando el método Caracterı́sticas Difusas.
15. Lectura y validación de distancias según el Tipo de dato.
16. Búsqueda de Productos en base a las distancias.
17. Configuración del interfaz para asignar las distancias.
18. Guardar entrada del usuario.
19. Modificar tipo de dato derivado.
20. Crear tipo de dato derivado.
21. Eliminar tipo de dato derivado.
22. Informar del cambio a los dueños del producto.
23. Consultar tipos primitivos.
24. Eliminar Atributos dependientes del Tipo Derivado.
25. Eliminar Valoraciones asociadas al atributo.
26. Gestión de clases de producto.
27. Modificar clase de producto.
28. Crear clase de producto.
29. Añadir atributos de clase.
109
110
30. Eliminar clase de producto.
31. Eliminar atributos de clase.
32. Actualizar Clase de Producto de los productos afectados.
33. Eliminar Valoraciones de productos asociadas a los atributos.
34. Informar del cambio a los dueños del producto.
35. Configurar parámetros.
36. Crear Cuenta para Registrarse.
37. Crear Cuenta Particular.
38. Crear Cuenta Empresa.
39. Modificar Cuenta.
40. Modificar Cuenta Particular.
41. Modificar Cuenta Empresa.
42. Eliminar Cuenta.
43. Eliminar productos asociados a la cuenta.
44. Identificarse en el sistema.
45. Crear Cuenta de Administrador.
46. Comprar producto.
47. Enviar mensaje.
48. Pujar por un producto.
49. Informar al usuario ganador de la subasta al finalizar.
111
50. Recuperar subastas tras una parada en la aplicación (caı́da del servidor por algún error
en tiempo de ejecución).
51. Generar gráfica de evolución de pujas.
52. Registrar Producto en el portal.
53. Registrar Producto para Venta Directa.
54. Registrar Producto para subasta.
55. Gestión de tipos derivados.
56. Consultar Mensajes Recibidos.
57. Consultar mensajes enviados.
58. Borrar Mensajes Recibidos.
59. Enviar mensaje a otro usuario.
60. Votar a comprador.
61. Consultar votaciones pendientes.
62. Votar a vendedor.
63. Listar valoraciones de un usuario por categorı́a.
64. Buscar Empresas por categorı́as.
65. Buscar Empresas por nombre.
66. Consultar productos asociados a la empresa y a la categorı́a.
67. Ordenar Empresas en base a la valoración en la categorı́a.
68. Registrar incidencia.
69. Listar incidencias.
112
70. Eliminar incidencias.
71. Borrar Mensajes caducados.
72. Generar informe de búsqueda.
73. Borrar búsquedas asociadas al informe.
74. Eliminar transacciones de compra y subasta caducadas.
75. Eliminar productos asociados a dichas transacciones.
76. Eliminar toda la información relativa a los productos borrados.
77. Resumir votaciones periódicamente, por usuario, calculando la media de las votaciones
individuales.
78. Borrar votaciones resumidas.
79. Solicitar sugerencia de localización.
80. Carga masiva de Productos vı́a XML.
81. Listar usuarios registrados.
82. Listar productos comprados, ganados en subasta, y aquellos por los que se haya pujado
y no hayan sido adquiridos.
83. Activar cuenta.
84. Recuperar contraseña.
85. Enviar informes a la cuenta de correo electrónico de la aplicación.
86. Listar informes generados por la aplicación.
87. Eliminar informes.
88. Consultar correos enviados a la cuenta de correo de la aplicación.
89. Borrar correos enviados a la aplicación.
113
90. Filtrar correos enviados a la aplicación por leı́dos / no leı́dos.
91. Listar los productos registrados de un usuario.
92. Listar el número de votaciones pendientes de un usuario por categorı́a.
4.4.1.4.
Fase de elaboración: Iteración 3
En esta iteración se implementa el modelo de análisis y de secuencia de los casos de
uso de la iteración 0. Los diagramas se implementan (al igual que los casos de uso) con Jude
Community, y se organizan por modelos. Al finalizar esta iteración se descubren las entidades
y se obtiene la respuesta a cómo hay que implementar los casos de uso de la iteración 0. Los
distintos diagramas pueden consultarse en:
Diagramas de análisis: apéndice B.2.1
Diagramas de secuencia: apéndice B.3.1
4.4.1.5.
En esta iteración se implementa el modelo de análisis y de secuencia de los casos de uso de
la iteración 1. Al finalizar esta iteración se descubren las entidades y se obtiene la respuesta a
cómo hay que implementar los casos de uso de la iteración 1. Los distintos diagramas pueden
consultarse en:
Diagramas de análisis: apéndice B.2.2
Diagramas de secuencia: apéndice B.3.2
4.4.1.6.
En esta iteración se crea el diagrama de clases a partir de los diagramas de secuencia. No
obstante, el diagrama mostrado en el proyecto es el diagrama final, que es el que se obtiene
tras la finalización de la Fase de construcción (Ver diagramas en el apéndice B.4.1). En esta
documentación sólo se muestran los diagramas de paquetes ya que los diagramas de clase son
114
demasiado grandes. Los diagramas de clase pueden encontrarse en el CD que se adjunta con
la documentación.
Cabe destacar que para la construcción de la aplicación se ha empleado la arquitectura de
tres capas:
Dominio: esta capa se corresponde con uno de los principales paquetes del sistema, y
en él se encuentra la lógica de negocio de la aplicación.
Presentación: en esta capa se encuentra todo el código necesario para presentar la información al usuario final.
Persistencia: es la capa usada para acceder a la base de datos del sistema.
En los diagramas se muestran las relaciones y dependencias entre los distintos paquetes
implementados para las tres capas citadas.
4.4.1.7.
Fase de construcción
Durante esta fase se procede a implementar los casos de uso según la priorización establecida. Consta de varias iteraciones. Normalmente cada iteración tendrá una duración de 2
semanas. Al finalizar cada iteración se van obteniendo pequeñas partes del sistema, que ya
son ejecutables.
Esta fase fue abordada desde Noviembre de 2008 hasta mediados de Junio de 2009, alrededor de 28 semanas. Si somos estrictos al aplicar el Proceso Unificado constarı́a de 14
iteraciones. Una vez concluida la fase se obtiene una primera versión completa.
4.4.2.
Resumen del Proceso Unificado aplicado al Proyecto
Resumidamente el Proceso Unificado consta de varias fases e iteraciones, y en cada iteración se realiza una tarea, que viene determinada por el plan de iteraciones, véase en la tabla
4.4.
Fase
Iteración
Iniciación
0
115
Tarea realizada
Identificar un subconjunto inicial de casos de uso y realizar los
diagramas.
Iniciación
1
Identificar el resto de casos de uso y crear los diagramas asociados.
Logros: analizados todos los Requisitos del Sistema, creado el Modelo de Casos de Uso
y realizada la Priorización de Casos de Uso, con lo que ya se tiene el orden en el que se
van a ir implementando las funcionalidades del sistema.
Elaboración
3
Crear los diagramas de análisis y de secuencia de los casos de
uso de la iteración 0.
Elaboración
4
Crear los diagramas de análisis y de secuencia de los casos de
uso de la iteración 1.
Elaboración
5
Obtención del diagrama de clases.
Logros: implementado el Modelo de Análisis, el de Secuencia y el Diagrama de Clases.
Ahora no sólo sabemos qué hay que hacer, también cómo hay que hacerlo.
Construcción
Resto
Obtener la implementación del sistema.
Logros: Se tiene una primera versión ejecutable de la aplicación.
Tabla 4.4: Cuadro resumen de la aplicación del Proceso Unificado al Proyecto
4.4.3.
Relaciones entre los Modelos implementados
En esta sección se pone de manifiesto la correspondencia entre cada uno de los modelos
creados. Mediante esta correspondencia (ver tablas 4.5 y 4.6) el lector podrá apreciar cómo
ha evolucionando un requisito, desde que fue capturado, hasta ser implementado, o dicho de
otra manera se va a lograr una trazabilidad de los requisitos.
Para entender las tablas 4.5 y 4.6, es necesario darse cuenta que los Ri hacen referencia a
los requisitos definidos en la sección 4.1, y los Bi a las figuras del apéndice B.
116
Requisitos
Diagrama de
Diagrama de
Diagrama de
Diagrama de
Caso de Uso
Análisis
secuencia
paquete
R1, R2, R3, R4
B.5
B.28
B.52, B.53
B.89
R5
B.6
B.29
B.54
B.89
R6
B.15
B.39
B.69
B.96
R7, R8, R9
B.14
B.37
B.66, B.67
B.89
R10, R11, R12,
B.4
B.27
B.51
B.87
B.2
B.30
B.57
B.93
B.19, B.8
B.40, B.32
B.59, B.56,
B.92
R13, R14, R15,
R16, R17
R18, R19, R20,
R21, R22
R23
B.61
R24, R25, R26,
B.9
B.33
B.58
B.94
R30, R31
B.1
B.26
B.50
B.88
R32, R33, R34,
B.3, B.12,
B.25, B.36,
B.49, B.64,
B.88
R35, R36, R37,
B.11
B.35
B.63
R45, R46, R47
B.7
B.31
B.55
B.91
R48
B.20
B.44
B.75
B.97
R49, R50
B.18
B.43
B.74
B.91
R51, R52, R53,
B.23
B.48
B.80, B.81
B.95
R27, R28, R29
R38, R39, R40,
R41, R42, R43,
R44
R54
Tabla 4.5: Trazabilidad de modelos de Proceso Unificado (I)
Requisitos
117
Diagrama de
Diagrama de
Diagrama de
Diagrama de
Caso de Uso
Análisis
secuencia
paquete
R55, R56
B.17
B.42
B.72, B.73
B.90
R57
B.24
B.38
B.65
B.82
R58, R59, R60,
B.21, B.22
B.44, B.45,
B.75, B.76,
B.97, B.98
R61, R62
B.13, B.20
B.46 B.47
B.77,B.78,
B.79
R63*
B.10
B.34
B.62, B.63
B.86
R64*
-
-
B.60, B.68
B.89
R65*
B.16
B.41
B.70
-
R66*
B.16
B.41
B.71
B.86
Tabla 4.6: Trazabilidad de modelos de Proceso Unificado (II)
(*) Durante el desarrollo del portal se han añadido requisitos que no se recogieron en el
catálogo:
R63 Búsqueda de empresas.
R64 Listar productos asociados al usuario registrado.
R65 Carga masiva de productos en el portal.
R66 Consultar caracterı́sticas de un producto.
Por último destacar también que aquellos requisitos sin modelo de paquetes han sido
desechados y como consecuencia no han sido implementados.
4.4.4.
Arquitectura del Sistema
Tal y como se describe en la metodologı́a del Proceso Unificado de desarrollo software,
los distintos modelos desarrollados dan lugar a una arquitectura del sistema, que es similar al
esqueleto de un edificio obtenido a partir de los planos. Por su parte a partir de la arquitectura se puede llegar a los distintos modelos. En la figura 4.6 se observa la arquitectura de la
aplicación desarrollada en el presente Proyecto.
118
Se trata de una arquitectura cliente servidor. En la parte del cliente se encuentra la capa
de presentación, el código HTML generado a partir de los JSP del lado del servidor. Cuando
el usuario hace una petición, se envı́a al servidor. En el servidor se redirige la petición hacia
la aplicación que se está describiendo, entrando en acción la capa que maneja las peticiones
(capa de presentación). Esta capa transforma la petición en un mensaje que es enviado a la
capa subyacente (el dominio). Finalmente el dominio aplica las operaciones asociadas a la
petición con el objetivo de construir una respuesta adecuada. Para ello, en la gran mayorı́a
de los casos, necesita acceder a los datos almacenados en la Base de Datos. Este acceso se
realiza por medio de la capa de persistencia.
Obsérvese que en las distintas capas de la aplicación (presentación, dominio y persistencia) están ubicados los paquetes software presentados en el anexo. Esto hace que exista una
estrecha relación entre los modelos y la arquitectura. Esta relación no sólo permite averiguar
a qué parte de la arquitectura pertenece un cierto paquete software, si no también qué parte
de la arquitectura corresponde a un cierto paquete software.
Figura 4.6: Arquitectura del sistema software desarrollado
119
120
Capı́tulo 5
Diseño de la interfaz
5.1. Elección de una interfaz adecuada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.2. Modelo navegacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
En una aplicación Web es muy importante el aspecto de la interfaz. Debe ser amigable e
intuitiva si se quiere que los usuarios lleguen a valorarla positivamente. Como consecuencia
es necesario realizar una serie de bocetos, que poco a poco nos vayan acercando a la interfaz adecuada. Pero no sólo la interfaz debe ser intuitiva, también debe ser intuitivo el modo
de navegar por la página, o dicho de otra manera, que el usuario se sienta cómodo cuando
está navegando por el portal debido a que la aplicación hace lo que el usuario espera. Esto
obliga a pensar en un modelo navegacional adecuado.
5.1.
Elección de una interfaz adecuada
En esta sección se presenta el flujo de trabajo seguido hasta seleccionar el aspecto actual
del portal. Durante esta fase de trabajo se han diseñado varios bocetos y finalmente se ha
seleccionado el más adecuado atendiendo a las guı́as establecidas en [57], que promueven
una interfaz en la que la distribución de los elementos de la página debe hacerse de modo que
los usuarios no tengan que pensar dónde está algo que desean buscar. Además se ha llegado
a un consenso entre el director y el autor de este proyecto y otras personas del grupo de
investigación ORETO [72] para la elección del diseño actual.
121
122
Capı́tulo 5. Diseño de la interfaz
Se presentan cuatro alternativas principalmente aunque se han diseñado más variantes.
Para la construcción de las alternativas presentadas se han empleado iconos gratuitos tomados
del portal IconArchive [10].
La alternativa 5.1 se desechó principalmente por tener demasiados colores, cosa que puede
resultar poco estético a los ojos de los usuarios. Otra razón es que distingue entre zona pública
y privada, aspecto que debe ser transparente al usuario. La alternativa 5.2 se desechó por el uso
de las pestañas, ya que sobrecarga la interfaz de elementos innecesarios, y por consiguiente
va en detrimento de las guı́as citadas en [57]. También por distinguir entre las zonas pública
y privada.
Finalmente la alternativa 5.3 es una interfaz muy ligera, intuitiva y fácil de entender y se
ha descartado por razones meramente estéticas, ya que la alternativa 5.4 es más agradable
visualmente.
Figura 5.1: Aspecto de la alternativa 1
5.1. Elección de una interfaz adecuada
123
124
5.2.
Modelo navegacional
Una vez elegida la interfaz, se implementa con código HTML, y posteriormente se transforma a código JSF, quedando lista para ir añadiendo páginas a la aplicación. En este punto es
importante darse cuanta que todas las páginas que añadamos a la aplicación van a tener partes
en común (cabecera, cuerpo, y pie de página), ya que si no lo hacemos duplicaremos y duplicaremos el código de las partes comunes en todas las páginas del proyecto. Esto presentarı́a
dos inconvenientes principalmente:
1. Un cambio en alguno de estos elementos comunes implicarı́a hacer el cambio en todas
y cada una de las páginas.
2. No estarı́amos aplicando uno de los principales principios de Ingenierı́a del Software:
la reutilización de componentes.
La solución al problema presentado es usar plantillas que nos permitan reutilizar los componentes comunes en cada una de las páginas del proyecto. Con esta solución las partes comunes
sólo se escriben una vez y posteriormente con las plantillas se indica qué parte se desea reuti-
5.2. Modelo navegacional
125
lizar, ensamblando a base de pequeños componentes una página. La tecnologı́a de plantillas
empleada en el proyecto es Tiles [37].
Finalmente, el conjunto de todas las páginas enlazadas entre sı́ forman lo que se denomina
el modelo navegacional. El modelo navegacional también debe ser intuitivo y simple, de
manera que la aplicación se comporte como espera el usuario (también se han aplicado las
guı́as [57] en lo posible). El modelo navegacional responde por tanto a la pregunta ¿cómo
podemos llegar a la página X desde la Y?
Es importante destacar que las páginas de la aplicación se clasifican en tres tipos:
Públicas: a ellas puede acceder cualquier usuario que navegue por internet y alcance el
portal.
Privadas: a ellas sólo pueden acceder los usuarios registrados en el portal. Son las páginas xxx bajo la dirección /privado/xxx.jsp.
Administración: a estas páginas solo puede acceder el administrador del sistema. Por
motivos de seguridad no existe ningún enlace en la zona pública ni en la zona privada
hacia estas páginas. Son las páginas xxx bajo la dirección /administracion/xxx.jsp.
El modelo navegacional se incluye en el apéndice D.
Otro aspecto importante a tratar según el World Wide Web Consortium (W3C) [82] es
separar el contenido de las páginas de la presentación [81]. Para ello se emplean hojas de
estilo en cascada (Cascading Style Sheets), abreviadamente CSS. Los Estilos definen la forma
de mostrar los elementos HTML y XML. CSS permite a los desarrolladores Web controlar el
estilo y el formato de múltiples páginas Web al mismo tiempo. Cualquier cambio en el estilo
marcado para un elemento en la CSS afectará a todas las páginas vinculadas a esa CSS en
las que aparezca ese elemento. En definitiva CSS proprociona grandes ventajas en cuanto a la
modificación del aspecto visual de la página, ya que permite dicha modificación empleando
un esfuerzo pequeño o moderado.
Es importante destacar que durante el desarrollo de la interfaz (páginas JSP, hojas de
estilo) es muy importante ajustarse a los estándares definidos por la W3C [82], ya que en
caso contrario la página no se visualizará correctamente en muchos navegadores. También
126
es importante seleccionar un navegador que siga los estándares para ir probando la interfaz
(como por ejemplo Mozilla Firefox).
La aplicación desarrollada en este PFC ha sido testeada con éxito en múltiples navegadores: Internet Explorer 5.0 (aunque no se recomienda su uso), Internet Explorer 5.5, Internet
Explorer 6.0, Internet Explorer 7.0, Internet Explorer 8.0, Mozilla Firefox, Konqueror, IceWeasel, Opera, Safari, Google Chrome.
Finalmente indicar que también se ha tenido en cuenta que una página colgada en internet
puede ser visualizada en cualquier parte del mundo. Por ello la interfaz puede ser visualizada tanto en español como en inglés. El idioma a mostrar es seleccionado automáticamente,
aprovechando el protocolo HTTP y la configuración del navegador con el que se visita la aplicación. De este modo, si el navegador está configurado con un idioma que no sea el español,
lo indicará en la petición HTTP, que leerá la aplicación y utilizará para enviar la interfaz en
inglés.
Capı́tulo 6
Manual de usuario
6.1. La Zona Pública . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.2. La Zona Privada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.3. La Zona de Administración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
La aplicación se divide en tres zonas bien diferenciadas en base a los usuarios que acceden
y al conjunto de funcionalidades ofrecidas. Las tres zonas son la pública, la privada y la de
administración. Ası́ tenemos que a la zona pública puede acceder cualquier usuario, esté o no
registrado, mientras que a la zona privada sólo pueden acceder aquellos usuarios registrados
como compradores o vendedores y el administrador. Finalmente, a la zona de administración
sólo puede acceder el administrador.
6.1.
La Zona Pública
La zona pública permite a los usuarios que visitan el portal buscar productos y empresas
mediante diferentes técnicas, ası́ como abrir una cuenta en el portal, activar dicha cuenta e
identificarse.
La búsqueda de empresas puede hacerse por categorı́as, por texto o bien por texto y categorı́as a la vez (ver figura 6.1). El resultado genera una lista de items similar al de la figura
6.2. Para cada empresa puede verse su valoración en la categorı́a de búsqueda (si es que se
especificó) y los productos asociados a dicha empresa. Si el usuario que lanza la búsqueda
127
128
Capı́tulo 6. Manual de usuario
de empresas está identificado en el sistema (se registró previamente) al lado del enlace ver
productos aparece otro enlace para contactar con dicha empresa mediante mensajes internos.
Figura 6.1: Interfaz para la búsqueda de empresas
Figura 6.2: Empresa localizada en una búsqueda de empresas
Por su parte, la búsqueda de productos es más compleja, puesto que la mayorı́a de los
usuarios del portal buscarán productos. Se pueden buscar productos especificando una descripción del producto, la categorı́a o bien una combinación de ambas (ver figura 6.3). Es
importante resaltar que se puede especificar al buscador de texto que trate de buscar productos en los que aparece una cadena de palabras seguidas como si sólo fuese una palabra,
restringiendo los resultados, con sólo encerrar ese conjunto de palabras entre dobles comillas
(Ejemplo “Canon powershot”). También es importante indicar que el buscador textual no es
sensible a mayúsculas ni a minúsculas, mejorando ası́ los resultados de búsqueda.
Figura 6.3: Búsqueda simplificada de productos
La página de resultados de productos muestra hasta 6 productos con la información detallada en la figura 6.5. Junto a los resultados se muestra una serie de opciones de visualización
6.1. La Zona Pública
129
(ver figura 6.4) que permiten ordenar por precio y por antigüedad, y especificar el mercado
en el que se está interesado (venta directa o subasta).
Figura 6.4: Opciones de visualización
Figura 6.5: Información básica de un producto
Si pese a todas estas facilidades el usuario no encuentra lo que busca puede probar con la
búsqueda avanzada. Se han implementado dos tipos de búsqueda avanzada que están integradas en una sola interfaz, la precisa y la difusa. La precisa busca exactamente lo que el usuario
especifica, mientras que la difusa muestra cosas parecidas a lo que el usuario especifica en
función del grado de incertidumbre. La búsqueda avanzada está necesariamente asociada a
una clase de producto y a la valoración de los atributos de dicha clase de producto. Por defecto se carga como categorı́a seleccionada la más general, mostrando todos los atributos de
dicha categorı́a. Las búsquedas precisas y difusas se realizan a lo largo de una rama de herencia, ası́, si se busca en la categorı́a más general, la búsqueda no sólo se realizará en la
categorı́a más general si no que se realizará en las categorı́as hijas.
Para que la aplicación haga una búsqueda precisa basta con asignar valores a los componentes de la izquierda de cada atributo, mientras que para que haga una búsqueda avanzada,
además hay que valorar los componentes de la derecha de cada atributo (ver figura 6.6). Para
la búsqueda precisa basta con indicar el valor o intervalo de valores deseado, mientras que
para la difusa además hay que especificar la precisión (en el caso de variables numéricas), el
orden de los conjuntos (en el caso de las variables de tipo conjunto), o bien clicar un checkbox en el caso de las variables textuales. Opcionalmente puede indicarse la importancia del
atributo.
130
Figura 6.6: Atributo asociado a una categorı́a en la búsqueda avanzada
En la búsqueda avanzada pueden especificarse tanto atributos difusos como precisos, con
lo que también pueden realizarse búsquedas preciso-difusas.
Los resultados de la búsqueda precisa únicamente dan lugar a una serie de páginas con la
información básica de los productos localizados.
Los resultados de la búsqueda avanzada muestran filtros con la intención de ayudar al
usuario a localizar su producto. Puede filtrarse en base a etiquetas lingüı́sticas de la lógica
difusa Lo que buscas, casi lo que buscas y lejos de lo que buscas. Estos filtros (a grandes
rasgos) utilizan la distancia (el grado de parecido) entre el producto ideal del usuario y el
producto encontrado para clasificar los productos para clasificar.
Si el usuario indica dos o más atributos difusos en la búsqueda, en los resultados aparece otro servicio extra para intentar ayudar al usuario a encontrar lo que busca, el estudio
de atributos o variables. Este estudio intenta analizar la relación que hay entre los atributos
especificados (ver figura 6.7).
Figura 6.7: Estudio de relaciones entre variables
Si se supone que se ejecuta la aplicación y se llega al caso de la figura 6.7, y se estudia la
variable Precio, la aplicación generarı́a una serie de “reglas”que indican si existen productos
por menos precio, igual precio o más precio con más, menos o igual peso. Esto permite guiar
al usuario hasta su producto ideal.
Otra finalidad de la Zona Pública es permitir el registro de usuarios. Cuando un usuario
se registra puede hacerlo como empresa o como usuario particular. Para ello debe rellenar el
6.1. La Zona Pública
131
formulario de registro (particular o empresa) y enviar los datos al servidor.
Una vez registrado, la aplicación envı́a un correo electrónico a la dirección de e-mail
especificada por el usuario con el código de activación de la cuenta que acaba de crear. Una
vez recibido dicho e-mail, el usuario entra en la página de activación e introduce su login,
su contraseña y su número de activación. A continuación pulsa activar y la cuenta queda
activada. Si el usuario no activa la cuenta no puede identificarse en el sistema.
La compra y puja de productos aparece en la zona pública de la aplicación, pero está condicionado a que el usuario esté identificado en el sistema. Si el usuario está identificado y
pulsa el botón de compra de la figura 6.5, aparece una página similar a la de detalle de producto con un botón para comprar el producto en el caso de que lo desee, un enlace para
contactar con el vendedor y las valoraciones del vendedor en las distintas clases de producto
en las que está involucrado. Si el usuario pulsa el botón de puja aparece un botón para formalizar la puja, un enlace para contactar con el vendedor, las valoraciones del vendedor en las
distintas clases de producto, un componente para escribir la cantidad que desea pujar y una
gráfica para ver la evolución de las pujas durante la subasta (ver figura 6.8).
Figura 6.8: Componente para pujar por un producto
Es preciso resaltar que aunque la compra y la puja de productos se encuentra en la Zona
132
Pública, semánticamente pertenece a la Zona Privada que se describe en la siguiente sección.
Por último indicar que existe un videotutorial sobre la zona pública, disponible para cualquier usuario que visite el portal, a través de un enlace situado cerca del enlace de registro
(ver figura 6.9).
Figura 6.9: Enlace al videotutorial
6.2.
La Zona Privada
Esta zona es a la que un usuario,registrado y activo, puede acceder. En ella se ofrecen las
siguientes funcionalidades (ver figura 6.10):
Consulta de los últimos 6 mensajes recibidos.
Consulta de los últimos 6 mensajes enviados.
Venta de Productos.
Últimas 4 votaciones pendientes del mercado de venta directa.
Últimas 4 votaciones pendientes del mercado de subastas.
Registro de incidencias.
Visualización de productos adquiridos tanto del mercado de venta directa como del de
subasta.
Visualización de productos vendidos tanto en el mercado de venta directa como en el
de subasta.
Visualización de todos los mensajes enviados y recibidos.
Visualización de todas las votaciones pendientes.
6.2. La Zona Privada
133
Modificar los datos asociados a la cuenta.
Darse de baja.
Figura 6.10: Aspecto del cuadro de opciones de la zona privada
La venta de productos sólo es posible si el usuario tiene el perfil vendedor. En la figura
6.10 el usuario no dispone del perfil vendedor. La figura 6.11 muestra la interfaz de registro
de productos, en la que para registrar un producto es necesario indicar la clase de producto en
la que se quiere vender, y a continuación pulsar en el enlace de la derecha. A continuación se
muestra un formulario con los campos a rellenar para el producto.
Figura 6.11: Interfaz de venta de productos (para un vendedor)
El formulario de registro del producto (ver figura 6.12) consta de dos partes: una de descripción general común a todas las clases de productos y otra de atributos especı́ficos de la
134
clase.
En la parte de descripción general es obligatorio rellenar todos los campos acompañados
de un asterisco. Los campos acompañados de dos asteriscos funcionan de la siguiente manera.
Si se especifica que el mercado va a pertenecer al mercado de venta directa, entonces hay que
rellenar del campo de precio de venta acompañado de dos asteriscos. Si se especifica que el
producto va a pertenecer al mercado de subastas, entonces hay que especificar el precio de
subasta, y la fecha y hora de comienzo (acompañados de dos asteriscos).
En la parte de atributos especı́ficos no es necesario rellenar todos, basta con rellenar únicamente los atributos en los que esté interesado el vendedor.
Figura 6.12: Formulario de venta de productos
El registro de incidencias sirve para que tanto compradores como vendedores puedan
indicar si han tenido algún problema durante la compra-adquisición de un producto, y quede
constancia de ello, con objeto de tomar las medidas necesarias. Para registrar una incidencia
es necesario pulsar en el enlace proporcionado. Al pulsar aparece un formulario de registro
de incidencias en el que hay que especificar el login del usuario que provoca la incidencia, el
6.3. La Zona de Administración
135
identificador del producto con el que está relacionada y la descripción.
Finalmente destacar la parte de las votaciones. Para realizar una votación es necesario
seleccionar la valoración y pulsar en el enlace votar situado al lado de la valoración (ver
figura 6.13).
Figura 6.13: Interfaz de votación
También existe un videotutorial de la Zona Privada disponible, mediante un enlace similar
al videotutorial de la zona pública y situado en el mismo lugar, para los usuarios registrados.
6.3.
La Zona de Administración
La Zona de Administración es de acceso exclusivo para los administradores y permite las
siguientes acciones (ver figura 6.14):
Gestión de usuarios.
• Crear otros administradores.
• Visualizar usuarios registrados.
• Eliminar usuarios registrados.
Alterar el comportamiento de la aplicación modificando los parámetros de configuración.
Reportes e informes.
• Consultar todos los correos enviados por la aplicación.
• Consultar las incidencias generadas por los usuarios.
• Consultar los informes generados automáticamente por la aplicación.
136
Gestión del catálogo de productos.
• Crear nuevos tipos de datos.
• Modificar nuevos tipos de datos.
• Eliminar tipos de datos derivados.
• Crear nuevas clases de productos.
• Modificar clases de productos.
• Eliminar clases de productos.
Visualizar la documentación de las clases Java que implementan las funcionalidades de
la aplicación, ası́ como las tablas de la base de datos y los mapeos con las clases Java.
Figura 6.14: Opciones de administración
6.3. La Zona de Administración
137
La parte más compleja es la gestión del catálogo. La creación de una nueva clase de
productos implica seleccionar la categorı́a padre, los atributos a heredar de la categorı́a padre,
y finalmente la definición de los atributos especı́ficos de la clase. Es necesario asociar un tipo
de datos para cada uno de los atributos especificados, por ello, si no existe el tipo deseado, el
administrador puede crearlo. La herencia sólo se da entre padres e hijos, pero no entre abuelos
y nietos.
La creación de un tipo de datos implica especificar un nombre de tipo, el supertipo primitivo del que deriva y las restricciones a las que está sometido. Las restricciones a las que
puede ser sometido un tipo primitivo son las siguientes:
Mayor que (aplicable a tipos numéricos únicamente).
Menor que (aplicable a tipos numéricos únicamente).
Mayor o igual que (aplicable a tipos numéricos únicamente).
Menor o igual que (aplicable a tipos numéricos únicamente).
Intervalo (aplicable a tipos numéricos únicamente).
Conjunto (aplicable a tipos textuales únicamente).
Al igual que para las otras zonas, también se ha creado un videotutorial para la zona de
administración disponible en el mismo lugar que en los casos anteriores.
138
Capı́tulo 7
Conclusiones
7.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
La construcción de un artefacto software es una tarea ardua que requiere de una gran
cantidad de conocimientos informáticos. El presente proyecto no hubiese sido posible sin
muchos de los conocimientos adquiridos a lo largo de la carrera. A continuación se hace una
reflexión sobre qué conocimientos han sido necesarios para la construcción del proyecto y
qué asignaturas están relacionadas con dichos conocimientos:
Lógica: conocimientos básicos sobre operaciones lógicas AND, OR, XOR, etc., usadas
con frecuencia durante la programación.
Metodologı́a y Tecnologı́a de la Programación: aporta las nociones básicas de programación usadas durante la implementación de todo el proyecto.
Ampliación de Programación: ha sido necesario incluir algoritmos de programación
avanzada para generar todas las combinaciones de una cierta cantidad de items.
Teorı́a de Autómatas y de Lenguajes Formales: conocimientos sobre expresiones regulares.
Estructuras de Datos y de la Información: la creación de estructuras de datos ha sido
una tarea muy frecuente durante la construcción de la aplicación.
139
140
Capı́tulo 7. Conclusiones
Bases de Datos: ha sido necesario diseñar y construir una base de datos robusta para la
aplicación.
Programación Concurrente: la comunicación entre procesos también ha tenido que
usarse para la adjudicación de las subastas.
Ampliación de Sistemas Operativos: el uso y concepto de memoria compartida también
se ha empleado.
Inteligencia Artificial: se ha construido un algoritmo de búsqueda difusa que ha requerido de conocimientos sobre lógica difusa.
Ingenierı́a del Software I: conocimientos sobre estructuración y modularización de sistemas software.
Procesadores de Lenguajes: conocimientos sobre expresiones regulares usadas en la
validación de la entrada del usuario y para la construcción de un lenguaje de tipado de
datos sencillo.
Redes: el conocimiento del protocolo HTTP es importante a la hora de construir aplicaciones WEB.
Interfaces de Usuario: conocimientos sobre el diseño de interfaces de usuario.
Modelos Avanzados de Bases de Datos: conocimientos sobre la definición e implantación de disparadores en la base de datos.
Sistemas de Interacción Persona-Computador: ha aportado principalmente el concepto
de estado de la aplicación y de concienciación del usuario (la interfaz debe ser lo más
intuitiva posible).
Planificación y Gestión de Sistemas de Información: aporta la noción de que la rigurosidad y la planificación dan más garantı́as de éxito que actuar sin pararse a pensar.
Es muy importante preparar un buen entorno de desarrollo antes de comenzar con la
implementación, ası́ como la planificación de qué es lo que se quiere realizar, con el objetivo
de que todo esté claro y se disponga de facilidades durante el desarrollo.
7.1. Trabajo futuro
141
Otra conclusión extraı́da es que pese a la existencia de organizaciones dedicadas a la
creación y divulgación de estándares, como por ejemplo el World Wide Web Consortium,
aún se siguen construyendo muchos sistemas software que no se adaptan a dichos estándares,
y que en definitiva supone una carga de trabajo extra para el programador. Un ejemplo claro de
esto puede encontrarse en los navegadores de hoy en dı́a. Durante la construcción de las hojas
de estilo se han empleado los estándares, y pese a ello existen navegadores que muestran
resultados no esperados, obligando a realizar un esfuerzo extra para forzar los resultados
deseados.
La organización del código, tal y como aconseja la Ingenierı́a del Software, favorece mucho el desarrollo, sobre todo porque cuando se quiere construir una aplicación de mediana
o gran envergadura, es necesario generar grandes cantidades de código que se volverı́an inmanejables. Pero la organización no sólo favorece al desarrollo si no que también favorece
pequeños cambios en los requisitos. Un ejemplo de esto último sucede mucho en el ámbito
empresarial, en el que el cliente cambia constantemente los requisitos, y si el código del proyecto carece de estructuración, uno de estos cambios podrı́a conllevar una gran cantidad de
tiempo.
Pese al gran esfuerzo que supone la construcción de un Proyecto, si éste no presenta
una interfaz atractiva visualmente, puede dar lugar a conclusiones erróneas sobre el esfuerzo
necesario para la implementación del mismo.
Por último señalar que se han cumplido los objetivos del proyecto y se ha obtenido un
resultado satisfactorio.
7.1.
Trabajo futuro
Son muchas las ideas que surgen durante el desarrollo del proyecto y que es necesario
expresar en esta sección por considerarse de gran importancia:
A pesar de que se tiene la certeza de que la interfaz es sencilla, intuitiva y de fácil
comprensión para el usuario, podrı́an mejorarse las alertas de error, para que en lugar de escribir un mensaje de texto en color rojo, se mostrase una ventana emergente
142
consiguiendo llamar la atención del usuario. De este modo conseguimos una mayor
concienciación por parte del usuario.
Actualmente si un producto registrado es comprado, éste deja de aparecer en los resultados de búsqueda. Tal vez podrı́a ser de gran utilidad dotar a la aplicación del concepto
de número de ejemplares de un producto. Ası́ cuando un vendedor registra un producto,
especificarı́a el número de unidades de productos iguales que desea poner a la venta.
El algoritmo de búsqueda difusa es lento frente a una gran cantidad de productos. Serı́a
muy útil centrarse en este algoritmo e intentar optimizarlo al máximo.
Implementar la capa de comunicaciones con los agentes ACOMDI y AVENDI mediante un middleware como Ice [91]. Esta capa estarı́a situada por encima de la capa de
dominio de la aplicación.
Permitir la modificación de los productos que un vendedor tiene registrados. Esto serı́a
una tarea bastante conflictiva a la que habrı́a que plantear una solución, respondiendo
a preguntas tales como: en subastas, si alguien ha pujado ya por un producto ¿deberı́a
permitirse la modificación?
Permitir al vendedor asociar varias imágenes a un producto. A la hora de mostrar los
productos el usuario dispondrı́a de algún tipo de control para ir pasando las distintas
imágenes.
Añadir enlaces de modificación del modelo de búsqueda difusa inicial del usuario a
cada uno de los productos mostrados. Al pulsar sobre este enlace el usuario estarı́a
indicando al sistema que busque productos similares al producto seleccionado. Esto
permitirı́a refinar aún más la búsqueda guiando al usuario hasta el producto deseado.
En la búsqueda avanzada mostrar únicamente los atributos más utilizados de la clase de
producto seleccionada cuando se hayan realizado un mı́nimo de búsquedas sobre dicha
clase.
Generar más gráficos que informen del estado de la aplicación.
7.1. Trabajo futuro
143
Modificar la página principal para mostrar productos destacados utilizando una serie de
criterios previamente establecidos. Ejemplo: mostrar chollos.
Modificar la página de pujas para añadir un enlace que permita pujar por una cantidad
mı́nima preestablecida que sea un tanto por ciento del precio de subasta actual. Además
incluir también un campo que permita especificar la cantidad deseada por el usuario
(como está actualmente) pero sin permitir que exceda una cierta cantidad con respecto
al precio actual de subasta.
Añadir la lógica necesaria para seguir la pista a los usuarios no registrados en el portal
y poder averiguar a partir de qué sitios llegan a la aplicación. Si la aplicación estuviese en un entorno de producción real, esta información serı́a muy útil con objeto de
publicitarse.
Integrar una pasarela de pagos en el portal, como PayPal [73] o eWay [35], para que los
compradores puedan realizar el pago online.
Pasar las constantes que afecten al aspecto visual del portal, que están ubicadas en las
interfaces Java, a la base de datos con el objetivo de que sea el administrador el que
decida el valor que deben tener. Por ejemplo el número de items por página.
Un sistema de recomendación de productos para usuarios registrados en base a búsquedas previas (sistema inteligente).
Implementar la arquitectura multiagente propuesta partiendo de la implementación del
portal.
144
Apéndice A
Diagramas de la base de datos
En este anexo se incluyen los diagramas de la base de datos. Se han partido en varias
páginas para mayor legibilidad.
A.1.
Diagrama entidad / interrelación
Se expone el diagrama entidad interrelación de la aplicación. Se muestra una panorámica de todo el diagrama (figura A.1), partido en cuatro secciones A, B, C y D. También se
muestran las cuatro secciones (A, B, C y D) con más detalle (figuras A.2, A.3, A.4 y A.5).
Los sı́mbolos que aparecen en los diagramas son los siguientes:
Entidades: se corresponden con los rectángulos.
Interrelaciones: los rombos.
Atributos: los cı́rculos unidos a las entidades.
Atributos identificadores que pueden formar la clave primaria en el diagrama relacional:
los cı́rculos azules.
Atributos compuestos: un atributo del que parten varios atributos normales.
Interrelaciones de herencia: triángulos pequeños unidos por el vértice superior a una
entidad y por los vértices inferiores como mı́nimo a otras dos entidades.
145
146
Capı́tulo A. Diagramas de la base de datos
Figura A.1: Vista panorámica del diagrama entidad interrelación
A.1. Diagrama entidad / interrelación
Figura A.2: Sección A del diagrama entidad interrelación
147
148
Figura A.3: Sección B del diagrama entidad interrelación
A.1. Diagrama entidad / interrelación
Figura A.4: Sección C del diagrama entidad interrelación
149
150
Figura A.5: Sección D del diagrama entidad interrelación
A.2. Diagrama relacional
A.2.
151
Diagrama relacional
También se adjunta el diagrama relacional. Como en el caso del diagrama conceptual,
se muestra una panorámica del diagrama, junto con las secciones en las que se va a partir,
ası́ como cada una de las secciones en que subdivide el original (ver figuras A.6, A.7, A.8,
A.9 y A.10).
Los iconos dentro de los campos de las relaciones (o tablas) indican lo siguiente:
Llave amarilla: clave primaria de la relación.
Llave gris: clave ajena.
Llave gris y amarilla: aquellos campos que son clave primaria y ajena al mismo tiempo.
152
Figura A.6: Vista panorámica del diagrama relacional
Figura A.7: Sección A del diagrama relacional
153
154
Figura A.8: Sección B del diagrama relacional
Figura A.9: Sección C del diagrama relacional
155
156
Figura A.10: Sección D del diagrama relacional
Apéndice B
Diagramas del Proceso Unificado
En este apéndice se adjuntan los modelos de análisis del Proceso Unificado para la aplicación.
B.1.
Diagramas de casos de uso
En este primer apartado se muestran todos los diagramas de casos de uso de la aplicación.
Los elementos que aparecen en este diagrama son:
Elipses: representan los casos de uso.
Esquema de persona: representan los actores del sistema.
Rectas: representan las dependencias y las comunicaciones entre los casos de uso, o
entre un caso de uso y un actor.
Los diagramas de casos de uso se han realizado con la herramienta Jude Community.
Todos los casos de uso se han empaquetado en el Modelo de casos de uso, uno de los modelos
propuestos por el Proceso Unificado.
B.1.1.
Diagramas de la iteración 0
Los diagramas de casos de uso de la iteración 0 se corresponden con las figuras ??, B.1,
B.4, B.5, B.6, B.7, B.8, B.2 y B.9. Puede observarse que los diagramas están organizados por
157
158
Capı́tulo B. Diagramas del Proceso Unificado
grupos de funcionalidades (sistema de búsqueda, sistema de gestión de cuentas, etc.).
Figura B.1: Casos de uso del sistema de configuración de parámetros
Figura B.2: Casos de uso del sistema de registro de productos
B.1. Diagramas de casos de uso
Figura B.3: Casos de uso del sistema de búsqueda
159
160
Figura B.4: Casos de uso para la gestión del catálogo de productos
Figura B.5: Casos de uso del sistema de gestión de cuentas
Figura B.6: Casos de uso del sistema de identificación
161
162
Figura B.7: Casos de uso del sistema de mensajes
Figura B.8: Casos de uso del sistema de gestión de productos
163
Figura B.9: Casos de uso del sistema de gestión de tipos de dato
B.1.2.
Los diagramas de casos de uso de la iteración 1 se corresponden con las figuras ??, B.11,
B.12, B.14, B.15, B.16, B.17, B.18, B.20, B.13, B.21, B.22 y B.23. Puede observarse que los
diagramas están organizados por grupos de funcionalidades (sistema de búsqueda, sistema de
gestión de cuentas, etc.).
164
Figura B.10: Casos de uso del sistema de búsqueda de empresas
Figura B.11: Casos de uso para la consulta de productos
Figura B.12: Casos de uso del buscador difuso
Figura B.13: Caso de uso generación de informe de búsqueda
165
166
Figura B.14: Casos de uso del sistema de gestión de cuentas de usuario (ampliación)
Figura B.15: Casos de uso del sistema de sugerencias de localización
Figura B.16: Casos de uso carga masiva de productos
167
168
Figura B.17: Caso de uso registro de incidencias
Figura B.18: Caso de uso envı́o de mensajes
Figura B.19: Casos de uso del sistema de votaciones
Figura B.20: Caso de uso envı́o de mensajes
169
170
Figura B.21: Caso de uso mantenimiento de productos
Figura B.22: Caso de uso mantenimiento de votaciones
171
172
B.2.
Diagramas de análisis
B.2.1.
Figura B.25: Análisis del sistema de búsqueda
B.2. Diagramas de análisis
Figura B.26: Análisis del sistema de configuración de parámetros
Figura B.27: Análisis del sistema de gestión de productos
173
174
Figura B.28: Análisis del sistema de gestión de cuentas
Figura B.29: Análisis del sistema de gestión de identificación
Figura B.30: Análisis del sistema de registro de productos
175
176
Figura B.31: Análisis del sistema de gestión de mensajes
Figura B.32: Análisis del sistema de adquisición de productos
Figura B.33: Análisis del sistema de registro de productos
177
178
B.2.2.
Figura B.34: Análisis del sistema de búsqueda de empresas
Figura B.35: Análisis del sistema de consulta de productos
Figura B.36: Análisis del sistema de búsqueda difusa
179
180
Figura B.37: Análisis del sistema de gestión de cuentas
Figura B.38: Análisis del sistema de gestión de correos
Figura B.39: Análisis del sistema de sugerencias
181
182
Figura B.40: Análisis del sistema de adquisición de productos
Figura B.41: Análisis del sistema de gestión de productos (más detalles)
Figura B.42: Análisis del sistema de incidencias
Figura B.43: Análisis del sistema de mensajes (avanzado)
183
184
Figura B.44: Análisis del sistema Tareas periódicas. Borrado de mensajes
Figura B.45: Análisis del sistema Tareas periódicas. Mantenimiento de productos
Figura B.46: Análisis del sistema Tareas periódicas. Generación de informes
Figura B.47: Análisis del sistema Tareas periódicas. Mantenimiento de votaciones
185
186
Figura B.48: Análisis del sistema de votaciones
B.3. Diagramas de secuencia
B.3.
Diagramas de secuencia
B.3.1.
Figura B.49: Diagrama de secuencia: registro de productos
187
188
Figura B.50: Diagrama de secuencia: configuración de parámetros
Figura B.51: Diagrama de secuencia: gestión del catálogo de productos
189
190
Figura B.52: Diagrama de secuencia: gestión de cuentas (A)
Figura B.53: Diagrama de secuencia: gestión de cuentas (B)
191
192
Figura B.54: Diagrama de secuencia: identificación
Figura B.55: Diagrama de secuencia: sistema de mensajes
193
194
Figura B.56: Diagrama de secuencia: adquisición de productos
Figura B.57: Diagrama de secuencia: registro de productos
195
196
Figura B.58: Diagrama de secuencia: gestión de tipos de datos
B.3.2.
Figura B.59: Diagrama de secuencia: adquisición de productos (A)
197
198
Figura B.60: Diagrama de secuencia: de adquisición de productos (B)
Figura B.61: Diagrama de secuencia: adquisición de productos (C)
Figura B.62: Diagrama de secuencia: búsqueda de empresas
199
200
Figura B.63: Diagrama de secuencia: consulta de productos
Figura B.64: Diagrama de secuencia: búsqueda difusa
201
202
Figura B.65: Diagrama de secuencia: sistema de correos
Figura B.66: Diagrama de secuencia: gestión de cuentas (A)
203
204
Figura B.67: Diagrama de secuencia: gestión de cuentas (B)
Figura B.68: Diagrama de secuencia: gestión de cuentas (C)
Figura B.69: Diagrama de secuencia: sugerencias de localización
205
206
Figura B.70: Diagrama de secuencia: carga masiva de productos
Figura B.71: Diagrama de secuencia: consultar caracterı́sticas de un producto
Figura B.72: Diagrama de secuencia: registro de incidencias (A)
207
208
Figura B.73: Diagrama de secuencia: registro de incidencias (B)
Figura B.74: Diagrama de secuencia: envı́o de mensajes
209
210
Figura B.75: Diagrama de secuencia: tareas periódicas. Borrado de mensajes
Figura B.76: Diagrama de secuencia: tareas periódicas. Informe de búsqueda (A)
211
212
Figura B.77: Diagrama de secuencia: tareas periódicas.Informe de búsqueda (B)
Figura B.78: Diagrama de secuencia: tareas periódicas. Mantenimiento de productos
213
214
Figura B.79: Diagrama de secuencia: tareas periódicas. Mantenimiento de votaciones
Figura B.80: Diagrama de secuencia: sistema de votaciones (A)
215
216
Figura B.81: Diagrama de secuencia: sistema de votaciones (B)
B.4. Diagramas de clase*
B.4.
217
Diagramas de clase*
(*) Sólo se incluyen los diagramas de paquetes, los de clase pueden encontrarse en el cd.
B.4.1.
Figura B.82: Dependencias del paquete dominio.correo
218
Figura B.83: Dependencias del paquete dominio.entidades
Figura B.84: Dependencias del paquete dominio.entidades.persistentes
219
220
Figura B.85: Dependencias del paquete dominio.gestionbusqueda.aprendizaje
Figura B.86: Dependencias del paquete dominio.gestionbusqueda
221
222
Figura B.87: Dependencias del paquete dominio.gestioncategorias
Figura B.88: Dependencias del paquete dominio.gestionconfiguracion
223
224
Figura B.89: Dependencias del paquete dominio.gestioncuentas
Figura B.90: Dependencias del paquete dominio.gestionincidencias
225
226
Figura B.91: Dependencias del paquete dominio.gestionmensajes
Figura B.92: Dependencias del paquete dominio.gestionproductos.adquisicion
227
228
Figura B.93: Dependencias del paquete dominio.gestionproductos
Figura B.94: Dependencias del paquete dominio.gestiontipos
229
230
Figura B.95: Dependencias del paquete dominio.gestionvotaciones
Figura B.96: Dependencias del paquete dominio.sugerencias
Figura B.97: Dependencias del paquete dominio.tareasperiodicas
231
232
Figura B.98: Dependencias del paquete dominio.tareasperiodicas.pdfgenerator
Figura B.99: Dependencias del paquete persistencia.hibernate
Figura B.100: Dependencias del paquete persistencia.hibernate.sessionmanagement
233
234
Figura B.101: Dependencias del paquete persistencia.hibernate.persistencia
Figura B.102: Dependencias del paquete presentacion.beans.administracion
235
236
Figura B.103: Dependencias del paquete presentacion.beans
Figura B.104: Dependencias del paquete presentacion.beans.privado
237
238
Figura B.105: Dependencias del paquete presentacion
Figura B.106: Dependencias del paquete presentacion.phaselistener
Apéndice C
Reuniones
En esta sección se describen las conclusiones de las distintas reuniones que tuvieron lugar
con el director de proyecto José Jesús Castro Sánchez.
C.1.
Reunión del dı́a 25 de Septiembre de 2008
En esta reunión se acuerda:
Escribir documento de resumen de requisitos capturados hasta la fecha.
Comenzar con la escritura de la documentación.
Una primera estructura de la documentación del Proyecto. Los capı́tulos que presentarı́a
la documentación serı́an:
• Método de trabajo (tecnologı́as, metodologı́as, planificación).
• Análisis.
• Diseño.
• Ejemplo de uso (tipo manual).
• Conclusiones y resultados (pruebas).
239
240
Capı́tulo C. Reuniones
C.2.
Reunión del dı́a 15 de Octubre de 2008
Se añaden los siguientes requisitos:
El sistema tiene que hacer un vuelco de los datos de votación en una tabla resumen: la
tabla en la que vuelca tiene el idusuario, categorı́a y valoración media.
Asociar la votación con la compra.
El sistema debe permitir la configuración de parámetros por parte del administrador.
Los parámetros a configurar son: fecha de caducidad, periodo denunciable, parámetros
difusos, periodo de caducidad de mensajes.
Corregir tipo de dato en la columna fechacaducidad de la tabla venta.
Por defecto no mostrar los productos vendidos en las búsquedas.
Para aquellos productos que ya se hayan vendido y que hayan quedado indexados en
google o en las cachés de los navegadores mostrar pero indicar que está vendido. Si ya
ha sido borrado se mostrará el mensaje de que el producto ya no existe.
Tiene que haber un proceso que compruebe qué productos han sido vendidos y los
saque de la tabla (borrarlo definitivamente pasado el tiempo de periodo denunciable).
Añadir valor medio a atributo.
Añadir funcionalidad de ordenar los productos por alguno de los atributos (en búsqueda
avanzada) y por precio y fecha de caducidad en las búsquedas normales.
Guardar las distancias según la búsqueda difusa (añadir columna a la tabla ValorBusqueda).
Información a mostrar tras una búsqueda de cada producto: titulo, fecha de caducidad,
precio, venta directa (cómpralo ya) o pujas (y no de pujas).
Por defecto se buscarán los productos tanto del mercado de venta directa como del
mercado de subastas. Habrá una opción de búsqueda (opcional) que permita indicar
solo subastas o solo venta directa.
C.3. Reunión del dı́a 22 de Octubre de 2008
241
Añadir campo precioActual a la tabla producto (precio de venta o ultima puja).
Añadir campo a búsqueda para guardar el nombre de la categorı́a.
Generar informe en pdf mensualmente y que lo envı́e por correo al administrador (que
informe sobre las búsquedas realizadas).
Añadir información a la denuncia (campo idcompra).
Añadir campo que indique la forma de adquisición del producto (compra directa o
puja).
Añadir campo categorı́a a la tabla empresa.
Búsqueda de empresas por categorı́as (ordenadas por votaciones obtenidas dentro de
esa categorı́a) y luego mostrar los productos asociados a la empresa y a la categorı́a.
Añadir fecha de caducidad al mensaje y permitir borrar al usuario.
En búsquedas con tipos de datos texto-conjunto permitir al usuario ordenar los elementos del conjunto y calcular distancias en base a ese orden.
El sistema mostrará a compradores y vendedores las votaciones pendientes.
C.3.
Reunión del dı́a 22 de Octubre de 2008
Se acuerda lo siguiente:
Respecto de la documentación reorganizar los requisitos de las iteraciones.
Añadir descripción corta al principio de las iteraciones.
Cambiar el nombre de sistema de denuncias a sistema de incidencias.
Una incidencia es un mensaje enviado por el usuario que tiene el problema al administrador.
242
Cambiar el nombre de Sistema de identificación a Sistema de autenticación (guardar la
información sensible del usuario encriptada).
Importancia para las no votaciones. Mostrar al usuario el número de transacciones en
el que no ha sido votado un usuario.
Cuando se elimina un producto eliminar también las votaciones pendientes relativas al
producto.
Enviar mensajes a otros usuarios registrados para preguntar dudas.
C.4.
Reunión del dı́a 11 de Noviembre de 2008
Se trata lo siguiente
Crear una clasificación inicial de productos.
Respecto del Buscador difuso:
• El usuario establece las caı́das de los conjuntos.
• El administrador establece los lı́mites de seguridad (barra de desplazamiento del
usuario).
• Mostrar los conjuntos difusos al usuario.
C.5.
Reunión del dı́a 18 de Noviembre de 2008
Modificaciones sobre el buscador difuso:
• Las búsquedas difusa y precisa se aplicarán sobre variables diferentes, nunca sobre
la misma.
• Una valoración fuera del máximo - mı́nimo por parte del usuario llevarı́a a un
error.
C.6. Reunión del dı́a 6 de Mayo de 2009
243
• La distribución de etiquetas se realizará de manera automática, en base a los resultados aplicando estadı́stica. Se aplicarı́a sobre el listado de pesos normalizados
difusos (Campana de gauss).
Diseño:
• Home: añadir enlaces para navegar por las categorı́as.
C.6.
Reunión del dı́a 6 de Mayo de 2009
En esta reunión se tratan aspectos a modificar y/o añadir a la aplicación tras ser sometida
a una prueba por parte del director de proyecto:
Para recuperar una contraseña es mejor usar la dirección de correo electrónico en lugar
del código de activación.
Mostrar los productos adquiridos por el usuario, incluyendo aquellos por los que haya
pujado y no haya adquirido.
Mostrar los productos subastados y vendidos por un usuario registrado.
Añadir un mensaje de confirmación al registrar un producto en el portal.
En el formulario de registro controlar el formato del DNI para que se guarden como un
número seguido de un guión y finalmente de la letra.
Verificar que el registro de productos se está haciendo de forma correcta.
Sustituir los mensajes de error, que aparecen embebidos en la página y de color rojo,
por ventanas emergentes que permitan al usuario ser más consciente de lo que está ocurriendo.
Al activar la cuenta mostrar un enlace continuar, para que los usuarios lo cliquen y
vayan a identificarse.
244
C.7.
Otras reuniones
Han tenido lugar muchas reuniones de supervisión del trabajo, en las que no se han introducido nuevos requisitos.
Apéndice D
Modelo navegacional
En este apéndice se incluyen los diagramas relativos al modelo navegacional de la aplicación. En primer lugar se muestra una panorámica de todo el modelo, y posteriormente se
muestra este modelo por fragmentos para que puedan apreciarse todos los detalles.
Para entender el modelo hay que tener en cuenta lo siguiente:
Los rectángulos amarillos representan las páginas de la aplicación.
Las etiquetas de texto indican acciones que pueden solicitarse en la página a la que
acompañan.
El rectángulo azul representa una página cualquiera.
Las lı́neas indican caminos de navegación y el sentido es desde donde está la etiqueta
hasta la página con la que se conecta.
245
246
Capı́tulo D. Modelo navegacional
Figura D.1: Vista panorámica del modelo navegacional
247
Figura D.2: Modelo navegacional (A)
248
Figura D.3: Modelo navegacional (B)
249
Figura D.4: Modelo navegacional (C)
250
Figura D.5: Modelo navegacional (D)
Apéndice E
Organización del CD adjunto
En este anexo se describe la organización del CD adjunto con el presente documento. Los
directorios y subdirectorios que pueden encontrarse en él son los siguientes:
Algunas Aplicaciones necesarias: aquı́ puede encontrar las aplicaciones esenciales para
visualizar los diagramas y ejecutar la aplicación:
• Apache Tomcat 6: necesario para ejecutar la aplicación.
• Jude Community: necesario para abrir los modelos de Casos de Uso, Análisis y
Secuencia.
• BrModelo: necesario para visualizar los diagramas relativos a la base de datos
(tanto el conceptual como el lógico).
Carga inicial Base de datos: ficheros generados para la primera carga de la base de
datos. El fichero eZocoBD.sql contiene una copia completa de la base de datos utilizada
durante el desarrollo.
Código Fuente: aquı́ puede encontrar todo el código fuente de la aplicación ası́ como
las librerı́as necesarias. Es una copia del proyecto eclipse generado para el desarrollo
de la aplicación, por lo que si dispone de Eclipse Ganymede, puede añadir el directorio
ezoco a su workspace y ası́ visualizar con facilidad la estructura del proyecto.
Demos: aquı́ encontrará los videotutoriales de las zonas pública, privada y de administración de la aplicación.
251
252
Capı́tulo E. Organización del CD adjunto
Diagramas: contiene los diagramas de la base de datos (tanto las imágenes como el
fichero .brM que se abre con BrModelo), los modelos de análisis (tanto las imágenes
como el fichero .jude que se abre con Jude Community) y finalmente la arquitectura y
el diagrama navegacional.
Diseño Interfaz: contiene todos los ficheros utilizados y realizados durante el diseño y
elección de la interfaz definitiva de la aplicación.
Documentación Látex: aquı́ se encuentra la documentación en código látex.
Ejecutables: aquı́ puede encontrar una versión ejecutable de la aplicación. Para poder
ejecutarla debe tener instalado Tomcat 6, Java 1.6 o posterior (recomendable), MySQL
5.5 y una instancia de la base de datos ezoco que puede crear a partir del fichero de base
de datos adjunto en el mismo directorio. El nombre de usuario y password de la base
de datos debe ser root.
Ejemplos de informes: contiene ejemplos de informes generados por la aplicación.
Imágenes Productos: aquı́ encontrará todas las imágenes de los productos registrados
en la base de datos adjunta.
PDF: aquı́ encontrará la versión en PDF de éste documento.
Requisitos No Funcionales: aquı́ encontrará ficheros con análisis acerca del rendimiento de la base de datos en función de las consultas estudiadas para incorporarlas a la
aplicación.
Reuniones: documentos con requisitos añadidos a la aplicación.
Bibliografı́a
[1] Centro de excelencia en tecnologı́as de la sociedad de la información y negocios
electrónicos para pymes. http://www.e-global.es/.
[2] Confederación provincial de empresarios ceoe-cepyme de ciudad real, centro comercial
ceoe ciudad real. http://www.cpe-cr.es/ecommerce/usuario/index.asp.
[3] G8
proyecto
piloto,
a
g8
global
marketplace
http://ec.europa.eu/archives/ISPO/ecommerce/g8/g8pp.html.
for
smes.
[4] Proyecto de investigación financiado por la consejerı́a de ciencia y tecnologı́a de la
junta de comunidades de castilla-la mancha (pac-06-0141), herramientas para comercio
electrónico: Desarrollo de una plataforma abierta para permitir actividades de comercio
electrónico, aplicaciones y agentes para su uso. http://dev.oreto.inf-cr.uclm.es/www/epactos/.
[5] 1-800-Flowers. Flowers, roses, gift baskets, flower bouquets - 1 - 800 - flowers.com.
http://ww12.1800flowers.com/.
[6] R. Agrawal, T. Imielinski, and A. Swami. Mining association rules between sets of items
in large databases. In Proceedings of the ACM SIGMOD International Conference on
Management of Data, pages 207–216, Washington D.C, EEUU, May 1993.
[7] Allapplabs. Hibernate tutorial. http://www.allapplabs.com/hibernate/features of hibernate.htm.
[8] Amazon. Amazon.com: Cdnow.
/3023481/ref=tab m gw l.
http://www.amazon.com/exec/obidos/tg/browse/-
[9] Amazon. Amazon.com: Online shopping for electronics, apparel, computers, books,
dvds and more. http://www.amazon.com/.
[10] Icon Archive. Icon archive - 23,800+ free icons, buddy icons, xp icons, vista icons,
desktop icons, aim icons. http://www.iconarchive.com/.
[11] R. Ashri, I. Rahwan, and M. Luck. Architectures for negotiating agents, volume
2691/2003 of Lecture notes in Computer Science, pages 136–146. Springer Berlin /
Heidelberg, 2003.
[12] C. Bartoli, C. Preist, and N.R. Jennings. Architecting for reuse: A Software framework
for automated negotiation. In Proc. 3rd Int. Workshop on Agent-Oriented Software Engineering, pages 86–98, 2002.
253
254
BIBLIOGRAFÍA
[13] Christian Bauer and Gavin King. Hibernate in Action. Manning, 2005.
[14] B.K. Mohanty and B. Bhasker. Product classification in the Internet business - a fuzzy
approach. Decision Support Systems, 38:611–619, 2005.
[15] Buy. Buy.com - computers, electronics, digital cameras, books, dvds, music, games,
software, toys, sports. http://www.buy.com/.
[16] C. Holahan. Auctions on eBay: A Dying Breed. Retrieved on May 16th, 2009 from
http://www.businessweek.com/technology/content/jun2008/tc2008062
112762.htm, 3 June 2008.
[17] D. Cameron. The New Business Platform for the Internet, 1997.
[18] J. Casillas and F. Martı́nez-López. Mining uncertain data with multiobjective genetic
fuzzy systems to be applied in consumer behaviour modelling. Expert Systems with
Applications, 36(2):1645–1659, 2009.
[19] J. L. Castro, J.J. Castro-Schez, and J.M. Zurita. Learning maximal structure rules
in fuzzy logic for knowledge acquisition in expert systems. Fuzzy Sets and Systems,
101(3):331–342, 1999.
[20] J.J. Castro-Schez, J.L. Castro, and J.M. Zurita. Fuzzy repertory table: a method for
acquiring knowledge about input variables to machine learning algorithm. IEEE Transactions on Fuzzy Systems, 12(1):123–139, 2004.
[21] J.J. Castro-Schez, N.R. Jennings, X. Luo, and N.R. Shadbolt. Acquiring domain knowledge for negotiating agents: a case of study. International Journal of HumanComputer Studies, 1(61):3–31, 2004.
[22] J.J. Castro-Schez, L. Jimenez, J. Moreno, and L. Rodriguez. Using Fuzzy Repertory
Table-based Technique for Decision Support. Decision Support Systems, 3(39):293–
307, 2005.
[23] Peter P. Chen. The entity-relationship model: a basis for the enterprise view of data. In
AFIPS National Computer Conference, pages 77–84, 1977.
[24] Peter Pin-Shan S. Chen. The entity-relationship model: Toward a unified view of data.
ACM Transactions on Database Systems, 1(1):9–36, 1976.
[25] E. F. Codd. A relational model of data for large shared data banks. Commun. ACM,
13(6):377–387, June 1970.
[26] coreservlets.com.
Jsf
(javaserver
http://www.coreservlets.com/JSF-Tutorial/.
faces)
y
apache
myfaces.
[27] D. Vakratsas and T. Ambler. How Advertising Works: What Do We Really Know?
Journal of Marketing, 63(1):26–43, 1999.
BIBLIOGRAFÍA
255
[28] A. De Miguel, M. Piattini, and E. Marcos. Diseño de Bases de Datos Relacionales,
chapter 8. Ra-Ma, 1999.
chapter 9, 10, 11. Ra-Ma, 1999.
[32] A. De Miguel, M. Piattini, and E. Marcos. Fundamentos y Modelos de Bases de Datos,
[33] A. De Miguel, M. Piattini, and E. Marcos. Fundamentos y Modelos de Bases de Datos,
[34] eBay.
ebay.es: El mayor portal de clasificados, compraventa y subastas.
http://www.ebay.es.
[35] eWay. eway - internet payment gateway and accept online credit card payments.
http://www.eway.com.au/.
[36] P. Faratin, N.R. Jennings, P. Buckle, and C. Sierra. Automated negotiation for provisioning virtual private networks using FIPA-compliant agents. In Proc. 5th Int. Conf. on
the Practical Application of Intelligent Agents and Multi-Agent Systems, pages 185–202,
2000.
[37] The Apache Software Foundation. Apache tiles 2 - home. http://tiles.apache.org/.
[38] Foundation for Intelligent Physical Agents. FIPA Agent Management Specification
(http://www.fipa.org/specs/fipa00023).
[39] Foundation for Intelligent Physical Agents. FIPA Agent Message Transport Service
Specification (http://www.fipa.org/specs/fipa00067).
[40] Foundation for Intelligent Physical Agents. (http://www.fipa.org).
[41] G. Saward and T. O’Dell. Micro and macro applications of case-based reasoning to
feature-based product selection. In Conf. on Expert Systems, 2000.
[42] M.M. Geipel and G. Weiss. A generic framework for argumentation-based negotiation.
4676/2007:209–223, 2007.
[43] José Felipe Lozano Gijón. Proyecto fin de carrera: “acomdi: Un agente comprador
difuso automático ”. Junio 2004.
[44] M. He, N.R. Jennings, and H-F. Leung. On agent-mediated electronic commerce. IEEE
Computer Society, 15(4):985–1003, 2003.
256
BIBLIOGRAFÍA
[45] K.V. Hindriks, C. Jonker, and D. Tykhonov. Towards an Open Negotiation Architecture for Heterogeneous Agents. In Proceedings of the 12th international workshop on
Cooperative Information Agents XII, pages 264–279. Springer, 2008.
[46] J. Albusac, L.M. López-López, J.M. Murillo, and J.J. Castro-Schez. Supporting Customer Searches in e-Marketplaces by means of Fuzzy Logic-based Machine Learning.
In Proceedings of The 2008 IEEE/WIC/ACM International Conference on Intelligent
Agents Technology and Web Intelligence, pages 892–896, Sydney, Australia, December
2008.
[47] Ivar Jacobson, Grady Booch, and James Rumbauch. The Unified Software development
process. Addison-wesley.
[48] N.R. Jennings, S. Parsons, C. Sierra, and P. Faratin. Automated Negotiation. In Proc.
5th Int. Conf. on Practical Application of Intelligent Agents and Multi-Agent Systems,
pages 23–30, 2000.
[49] J.J. Castro-Schez, D. Vallejo-Fernández, L. Rodriguez-Benitez, and J. Moreno-Garcı́a.
A Fuzzy Logic Based Approach to Improve Cataloguing and Searching in E-commerce
Portals, volume 12 of Lecture Notes in Business Information Processing, pages 316–
327. Springer-Verlag, 2008.
[50] C.M. Jonker, V. Robu, and J. Treur. An agent architecture for multi-attribute negotiation
using incomplete preference information. Autonomous Agents and Multi-Agent Systems,
15(2):221–252, 2007.
[51] Joomla.
Best of joomla - joomla template - eshop plazza.
http://www.bestofjoomla.com/component/option,com bestoftemplate/task,detail/Itemid,46/id,1703/.
[52] Mario Dı́az Justicia. Proyecto fin de carrera: “desarrollo de un agente vendedor difuso
para entornos de negociación automática en comercio electrónico. ”. Julio 2007.
[53] K. Srikumar and B. Bhasker. Personalized Product Selection in Internet Business. Journal of Electronic Commerce Research, 5(4):216–227, 2004.
[54] K. Srikumar and B.Bhasker. Personalized recommendations in E-Commerce. In 5th
World Congress on E-Business in 25th Mc Master World Congress, 2004.
[55] N. Rao Kowtha and T. Whai Ip Choon. Determinants of website development: a study of
electronic commerce in Singapore. Information & Management, 3(39):227–242, 2001.
[56] Krillion. Find national brands, locally - krillion. http://www.krillion.com/.
[57] Steve Krug. Don’t Make Me Think!: A Common Sense Approach to Web Usability. Que
Corp., Indianapolis, IN, USA, 2000.
[58] K.C. Laudon and J. P. Laudon. Management Information Systems: Managing the Digital
Firm. Prentice Hall, 9 edition, 2005.
BIBLIOGRAFÍA
257
[59] E. Mamdani and S. Assilian. An experiment in linguistic synthesis with a fuzzy logic
controller. Int. J. Man-Machine Studies, 7(1):1–13, 1975.
[60] F. Martı́nez-López and J. Casillas. Marketing intelligent systems for consumer behaviour modelling by a descriptive induction approach based on genetic fuzzy systems.
Industrial Marketing Management, page doi=10.1016/j.indmarman.2008.02.003, 2009.
[61] Antonio Gallardo Mendoza. Proyecto fin de carrera: “e-market-tool: Un portal para el
apoyo a la realización de negociación automática ”. Julio 2006.
[62] Microsoft.
Rendimiento de la base de datos.
es/library/ms190619.aspx, Enero 2009.
http://msdn2.microsoft.com/es-
[63] Sun Microsystems. Basic requirements of a javaserver faces application - the java ee 5
tutorial. http://java.sun.com/javaee/5/docs/tutorial/doc/bnaxj.html.
[64] Sun
Microsystems.
Javaserver
faces
technology
http://java.sun.com/javaee/javaserverfaces/reference/docs/index.html.
documentation.
[65] Sun Microsystems. Mysql :: Mysql 5.0 reference manual :: 12.7 funciones de
búsqueda de texto completo (full-text). http://dev.mysql.com/doc/refman/5.0/es/fulltextsearch.html.
[66] Sun Microsystems. Mysql :: Mysql 5.0 reference manual :: 15.6.4 restricciones
(constraints) foreign key. http://dev.mysql.com/doc/refman/5.0/es/innodb-foreign-keyconstraints.html.
[67] MySQL. Capı́tulo 14. motores de almacenamiento de mysql y tipos de tablas.
http://dev.mysql.com/doc/refman/5.0/es/storage-engines.html.
[68] MySQL.
Chapter
8.
creating
foreign
key
relationships.
http://dev.mysql.com/doc/workbench/en/wb-foreign-key-relationships.html.
[69] MySQL. Why mysql? http://www.mysql.com/why-mysql/.
[70] Noticiasdot. Portales de comercio electrónico explican sus formula para conseguir el
éxito. http://www.noticiasdot.com/publicaciones/2005/0605/1206/noticias/noticias 13060516.htm.
[71] T.Ñovak, D. Hoffman, and Y. Yung. Measuring the customer experience in online environments: A structural modelling approach. Marketing Science, 19(1):22–42, 2000.
[72] Grupo Oreto.
Grupo de
http://www.oreto.inf-cr.uclm.es/.
investigación
de
sistemas
inteligentes
oreto.
[73] PayPal. Bienvenido - paypal. http://www.paypal.es/es.
[74] The Apache Jakarta Project. The jakarta site - the jakarta project – java related products.
http://jakarta.apache.org/.
258
BIBLIOGRAFÍA
[75] R.R. Yager. Fuzzy logic methods in recommended systems. Fuzzy Sets and Systems,
136:133–149, 2003.
[76] S. Klaue, K. Kurbel, and I. Loutchko. Automated Negotiation on Agent-Based eMarketplaces: An Overview. In Proceedings of the 13th Bled Electronic Commerce
Conference, pages 508–519, 2001.
[77] Shopnow. http://www.shopnow.com/.
[78] Ecommerce Times.
[79] Todocoleccion. Comprar y vender en todocoleccion - subastas - tiendas - compra y venta
de antiguedades y coleccionismo. http://www.todocoleccion.net/.
[80] E. Turban, J. Lee, D. King, and H. Chung. Electronic Commerce: A Managerial Perspective. Prentice Hall, 1 edition, 2000.
[81] World Wide Web Consortium (W3C).
http://www.w3c.es/divulgacion/guiasbreves/HojasEstilo.
Guı́a
breve
de
css.
[82] World Wide Web Consortium (W3C). World wide web consortium - oficina española.
http://www.w3c.es/.
[83] Wikipedia.
E-commerce
http://es.wikipedia.org/wiki/ECommerce.
wikipedia,
[84] Wikipedia.
Eclipse (software) - wikipedia,
http://es.wikipedia.org/wiki/Eclipse (software).
la
enciclopedia
la
enciclopedia
libre.
libre.
[85] wikipedia.org. Hibernate. http://es.wikipedia.org/wiki/Hibernate, 2009.
[86] M.J. Wooldridge and Jennings. Intelligent agents: theory and practice. The Knowledge
Engineering Review, 2(10):115–152, 1995.
[87] W.P. Lee, C.H. Liu, and C.C. Lu. Intelligent agent-based systems for personalized recommendations in Internet Commerce. Expert Systems With Applications, 22:275–284,
2002.
[88] www.apl.jhu.edu.
A tutorial on java servlets and java server pages (jsp).
http://www.apl.jhu.edu/ hall/java/Servlet-Tutorial/.
[89] Yahoo¡. Yahoo¡small business: Domain names, web hosting, e-commerce, email, and
online marketing. http://smallbusiness.yahoo.com/.
[90] Y.U. Ryu. A Hierarchical Constraint Satisfaction Approach to Product Selection for
Electronic Shopping Support. IEEE Transactions on Systems, Man., and Cybernetics PART A: Systems and Humans, 29(6):525–532, 1999.
[91] ZeroC. The internet communications engine (ice). http://www.zeroc.com/ice.html.

UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR

Transcripción

Documentos relacionados

Mapeo facial de emociones sintéticas - UPM ASLab

universidad de castilla-la mancha escuela superior

Clase 14

ESCUELA T´ECNICA SUPERIOR DE INGENIERÍA DE