Universidad Católica de Valparaíso

Facultad de Ingeniería
Escuela de Ingeniería Industrial

Modelado de un Sitio Web de Comercio Electrónico

para Mejorar la Interacción Bajo la Filosofía CRM

por

Rodrigo Alfaro Arancibia

Tesis para optar al grado de

Magíster en Ingeniería Industrial, Mención Gestión

Prof. Guía: Guillermo Bustos Reinoso

Septiembre, 2001
2

Saludo a mis padres Elsa y Marcelo

a mi esposa Talia
a mis amigos
y a todos los que me ayudaron
a terminar esta etapa...
 3

Índice
Índice .......................................................................................................................... 3

Lista de Figuras ......................................................................................................... 5

Lista de Tablas........................................................................................................... 7

Lista de Abreviaturas y Siglas.................................................................................. 8

Resumen..................................................................................................................... 9

1. Introducción...................................................................................................... 10

2. ¿Por qué modelar conceptualmente un sitio web? ....................................... 12

2.1 Modelar para mejorar la calidad del sistema ............................................... 13
2.2 Modelar para mejorar la relación con los clientes ....................................... 14
3. Esquema Navegacional.................................................................................... 23
3.1 Criterios de Búsqueda ................................................................................. 25
3.2 Resumen de OOHDM ................................................................................. 26
3.3 Adaptación de OOHDM al DER................................................................... 30
4. Diagrama Entidad Relacionamiento Integrado .............................................. 33
4.1 DER asociado al Esquema Navegacional ................................................... 33
4.2 Asociaciones entre Entidades de ambos DERs .......................................... 34
4.3 Análisis de las asociaciones entre las entidades......................................... 36
5. Desarrollo de un Datawarehouse .................................................................... 44
5.1 Diseño lógico de la base de datos............................................................... 44
5.2 Integración................................................................................................... 48
6. Datamining ........................................................................................................ 51
6.1 Web Mining ................................................................................................. 51
6.1.1 Web Mining de contenido ............................................................................................. 51
6.1.2 Web Mining de estructura............................................................................................. 52
6.1.3 Web Mining de uso....................................................................................................... 52
6.2 Web Mining de uso...................................................................................... 52
6.2.1 Datos de Pre-procesamiento para Mining ..................................................................... 53
6.2.2 Descubrimiento de patrones ......................................................................................... 54
6.2.3 Análisis de patrones ..................................................................................................... 56
6.3 Desarrollo de un Datamining ....................................................................... 57
6.3.1 Análisis estadístico ....................................................................................................... 57
6.3.2 Reglas de asociación ................................................................................................... 58
6.3.3 Clasificación ................................................................................................................. 58
6.3.4 Patrón secuencial......................................................................................................... 58
6.3.5 Modelamiento dependiente........................................................................................... 58
 4

7. Aplicación del Datamining al Datawarehouse ............................................... 60

7.1 Segmentación ............................................................................................. 60
7.2 Búsqueda de los clientes más rentables ..................................................... 61
7.3 Estimación de la fidelidad de un cliente....................................................... 63
8. Conclusiones .................................................................................................... 64

Anexo 1: Extracto de Notación de la Metodología OOHDM ................................. 67

1 Introducción .................................................................................................... 67
2 Esquema de Contextos Navegacionales ........................................................ 71
2.1 Contexto Navegacional ....................................................................................................... 71
2.1.1 Representación de los contextos .................................................................................. 71
2.1.2 Contexto dinámico........................................................................................................ 76
2.1.3 Contexto Persistente y no Persistente .......................................................................... 78
2.1.4 Generalización de Contexto.......................................................................................... 78
2.1.5 Navegación en los Contextos ....................................................................................... 79
2.1.5 Cartas de un Contexto.................................................................................................. 81
2.2 Estructuras de acceso........................................................................................................ 83
2.3 Clases en Contexto............................................................................................................ 88
2.4 Esquema de Contextos de Navegación .............................................................................. 90
Anexo 2: Diccionario de Datos del DER Integrado ............................................... 91

Anexo 3: Desarrollo de un caso ............................................................................. 93

Apéndice 1: Sistema de Ventas On-Line www.marraqueta.cl ............................. 95

1 Antecedentes .................................................................................................. 95
2 Sistema de Información a Ser Modelado ........................................................ 96
3 Solución ........................................................................................................ 100
Modelamiento Dinámico:......................................................................................................... 101
Modelamiento Estático:........................................................................................................... 117
Modelamiento Funcional: ........................................................................................................ 126
Bibliografía ............................................................................................................. 145
 5

Lista de Figuras
Figura 2.2 – Tres etapas de CRM ........................................................................ 16
Figura 3.1 – Diagrama Entidad Relacionamiento del Sitio www.marraqueta.cl
[Bustos&Jaar99] ............................................................................... 24
Figura 3.2 – Diagrama Entidad Relacionamiento asociado a la Navegación ....... 26
Figura 3.4 – Contexto de navegación por consulta .............................................. 28
Figura 3.5 – Consulta de contextos de distintas clases........................................ 29
Figura 3.6 – Contexto de creación........................................................................ 29
Figura 3.7 – Ejemplo del Esquema Navegacional asociado................................. 30
Figura 3.8 – Esquema Navegacional modificado ................................................. 31
Figura 3.9 – Esquema Navegacional de www.marraqueta.cl ............................... 32
Figura 4.1 – DER asociado el Esquema Navegacional ........................................ 33
Figura 4.2 – Asociaciones entre Entidades de ambos DERs ............................... 34
Figura 4.3 – Asociaciones entre Entidades de ambos DERs ............................... 35
Figura 4.4 – Asociaciones entre Entidades .......................................................... 37
Figura 4.5 – Asociaciones entre Entidades: Categoría – Criterio de Búsqueda por
Categorías ........................................................................................ 38
Figura 4.6 – Asociaciones entre Entidades: Pedido – Pedidos Realizados.......... 39
Figura 4.7 – Asociaciones entre Entidades: Cliente – Visitante en Línea............. 40
Figura 4.8 – Asociaciones entre Entidades: Cesta – Cesta de Productos............ 41
Figura 4.9 – Asociaciones entre Entidades: Producto – Productos ...................... 42
Figura 4.10 – Diagrama Entidad Relacionamiento Integrado ................................. 43
Figura 6.1 – Web Mining de Uso .......................................................................... 53
Figura 7.1 – Gráfico de Segmentación ................................................................. 61
Figura 7.2 – Clientes que generan más ingresos. ................................................ 62
Figura 7.3 – Clientes más fieles. .......................................................................... 63
Figura A1.1 – Esquema Conceptual ....................................................................... 69
Figura A1.2 – Esquema Navegacional.................................................................... 70
Figura A1.3 – Representación de un contexto ........................................................ 72
Figura A1.4 – ejemplo de un contexto .................................................................... 72
Figura A1.5 – Contexto con elementos de varias clases ........................................ 73
Figura A1.6 – Contexto de instancias ..................................................................... 73
Figura A1.7 – Contexto de navegación por consulta .............................................. 74
Figura A1.8 – Grupo de contexto ............................................................................ 74
Figura A1.9 – ejemplo de grupo de contexto .......................................................... 75
Figura A1.10 – Entrada de parámetros para un contexto e grupo de contexto......... 75
Figura A1.11 – Contexto de navegación dinámico.................................................... 76
Figura A1.12 – Contexto de creación........................................................................ 77
Figura A1.13 – Generalización de contextos ............................................................ 79
Figura A1.14 – Cartas de contexto o grupo de contexto........................................... 81
Figura A1.15 – Carta del contexto ............................................................................ 82
Figura A1.16 – Carta de contexto o grupo de contexto............................................. 83
Figura A1.17 – estructura de acceso profesores ...................................................... 83
 6

Figura A1.18 – estructura de acceso con múltiples criterios de ordenación ............. 83

Figura A1.19 – Índice con un contexto como destino ............................................... 84
Figura A1.20 – Índice con un contexto como destino ............................................... 84
Figura A1.21 – Índice con varios contextos como destino ........................................ 85
Figura A1.22 – estructura de acceso jerárquica........................................................ 85
Figura A1.23 – Cartas de estructura de acceso profesores...................................... 86
Figura A1.24 – Cartas de estructura de acceso profesores...................................... 87
Figura A1.25 – Cartas de estructura de acceso profesores: Áreas .......................... 88
Figura A1.26 – Clase en contexto profesor por Área ................................................ 89
Figura A1.27 – Esquema de contextos de navegación............................................. 90
 7

Lista de Tablas
Tabla 5.1 – Reglas para la implementación de relacionamientos [Heuser01] ......... 45
Tabla 5.2 – Simbología utilizada en un diccionario de datos ................................... 46
Tabla 7.1 – Resultado de la Segmentación por tipo de productos comprados........ 61
Tabla 7.2 – Clientes que generan más ingresos. .................................................... 62
Tabla 7.3 – Clientes más fieles................................................................................ 63
 8

Lista de Abreviaturas y Siglas

CD = Compact Disc
CRM = Customer Relationship Management
e-CRM = Electronic Customer Relationship Management
DER = Diagrama Entidad Relacionamiento
FAQ = Frequently Asked Questions
HTML = Hyper Text Markup Language
HTTP = Hyper Text Transfer Protocol
ICRM = Internet Customer Relationship Management
IMM = Internet Interaction Management
IRM = Internet Relationship Management
OOHDM = Object-Oriented Hypermedia Design Method
pág. = Página
UML = Unified Modeling Language
URL = Uniform Resouce Locator
www = World Wide Web
 9

Resumen
El gran auge de Internet, el crecimiento explosivo de transacciones vía web y
la formalización de una filosofía orientada al cliente, a través de CRM, motiva a que
un gran número de empresas intenten realizar ventas en línea a través de la red.

No obstante, muchos sitios de comercio electrónico se elaboran y ponen en

marcha sin una adecuada planificación y modelamiento, lo que se traduce en que no
se utilicen todas las potencialidades que entrega Internet o las nuevas tecnologías de
información. Se vuelve a confirmar entonces la necesidad de enfatizar que se debe
modelar conceptualmente un sistema antes de implementarlo.

El objetivo de esta investigación es obtener un modelo que registre la relación

o interacción de los clientes o visitantes con un sitio web de comercio electrónico. De
esta forma se podrá obtener información para mejorar esta relación en distintos as-
pectos, tales como: estructura del sitio, promoción de productos a clientes específi-
cos, precios variables (dinámicos), negociación en línea, etc.

Se utiliza un esquema navegacional que representa las interacciones de los

visitantes del sitio web a través de una metodología propuesta en [Schwa-
be&Vilain99] y se ha asociado con el Diagrama Entidad Relacionamiento.

Un aporte específico de la investigación es la integración que se realiza entre

el DER que registra interacciones del sitio con el DER operacional del negocio, esta
metodología puede será de gran ayuda, si se utiliza en la primera etapa del Web Mi-
ning de uso. Se debe hacer notar también, que la integración entre estos diagramas
se produce de forma natural y sin recurrir a otros mecanismos más que los existentes
en el modelamiento conceptual del Diagrama Entidad Relacionamiento.

Se desarrolla un datawarehouse a partir del DER Integrado y se proponen al-

gunas aplicaciones simples de información que se podría obtener de los registros,
basándose en la filosofía CRM. Aunque esta filosofía sirvió de marco para obtener un
tipo de información, no debería ser una restricción para obtener otra información que
pueda apoyar a los tomadores de decisiones.

Finalmente, se plantea que esta investigación debiera ser de utilidad para futu-
ros trabajos e investigaciones que se realizarán en torno al tema de sistemas en In-
ternet e intranets que, debido a la estandarización y a la explosión de las comunica-
ciones, debieran aumentar cada vez más.

Palabras Claves: Web, Web Mining, Datawarehouse, Datamining, CRM, DER,

OOHDM, Comercio electrónico, Internet.
 10

1. Introducción
El gran auge de Internet y el crecimiento explosivo de transacciones vía web,
motiva a que un gran número de empresas intenten realizar ventas en línea a través
de la red. Sin embargo, muchos sitios de comercio electrónico se elaboran y ponen
en marcha sin una adecuada planificación y modelamiento, lo que se traduce en que
no se utilicen todas las potencialidades que entrega Internet o las nuevas tecnologías
de información.

Por otra parte, la formalización de una filosofía orientada al cliente, a través de

CRM (Customer Relationship Management), tiene un potencial de desarrollo mucho
mayor debido a la explosiva conectividad y riqueza de la comunicación que se puede
establecer por medio de Internet.

Es así como diversos autores han asociado Internet con CRM, asignándole
diversos nombres, tales como: IMM (Internet Interaction Management), ICRM (Inter-
net Customer Relationship Management), IRM (Internet Relationship Management),
e-CRM (Electronic Customer Relationship Management), que buscan maximizar la
satisfacción de los clientes y mejorar la calidad de las relaciones con los clientes, a
través de Internet.

Se vuelve a confirmar entonces la necesidad de enfatizar que se debe mode-

lar conceptualmente un sistema antes de implementarlo. Durante el modelamiento
conceptual debe describir qué hará el sistema, para posteriormente determinar cómo
deberá hacerlo.

El objetivo de esta investigación es obtener un modelo que registre la relación

o interacción de los clientes o visitantes con un sitio web de comercio electrónico. De
esta forma se puede obtener información para mejorar esta relación en distintos as-
pectos, tales como: estructura del sitio, promoción de productos a clientes específi-
cos, precios variables (dinámicos), negociación en línea, etc.

El informe está estructurado en siete capítulos más las conclusiones. El primer

capítulo introduce a los lectores al tema y describir los objetivos del estudio.

En el segundo capítulo se fundamenta la necesidad de modelar un sitio web

antes de ponerlo en marcha, principalmente por dos razones: por una parte, permite
mejorar la calidad de la aplicación y su posterior adaptación y mantención, y por otra
parte, mejorar la calidad de las relaciones con los clientes, tal como lo propone CRM.

En el tercer capítulo se presenta un esquema navegacional que representa las

interacciones de los visitantes del sitio web www.marraqueta.cl, a través de una me-
todología propuesta en [Schwabe&Vilain99]. Este modelo es adaptado para asociarlo
 11

con un Diagrama Entidad Relacionamiento y permite registrar las interacciones de

los usuarios en el sitio web.

El cuarto capítulo muestra cómo se puede integrar el DER que registra inter-
acciones del sitio con el DER operacional. De esta forma, se pretende que al elabo-
rar un DER que represente aspectos operacionales y aspectos navegacionales, se
pueda apoyar la toma de decisiones en todo el espectro del negocio, es decir, desde
decisiones operacionales, productos ofrecidos, hasta modificaciones de la estructura
e interfaz del sitio.

En el capítulo quinto, se realizan los pasos necesarios para llevar el DER Inte-
grado que se obtuvo en el capítulo anterior a una base de datos del tipo dataware-
house. Esta base de datos debe apoyar a los tomadores de decisiones en la bús-
queda de información y en la obtención de relaciones entre datos que no se obten-
dría fácilmente de la base de datos operacional.

En el sexto capítulo se establecen los fundamentos del Web Mining, enfocán-

dose principalmente en el Web Mining de uso, como un marco conceptual y metodo-
lógico para obtener información de los sitios web. En el contexto del Web Mining de
uso, el resultado de esta investigación apoya de gran manera su primera etapa, de
pre-procesamiento, ya que otorga una metodología permite obtener datos en forma
ordenada para posteriormente realizar la búsqueda de patrones.

Posteriormente, se desarrollan algunas aplicaciones para obtener información

del ejemplo utilizado en todo el documento, de esta forma, se muestran las herra-
mientas propuestas para obtener información que ayude a tomar decisiones, basán-
dose en la filosofía CRM.

A continuación, se establecen las conclusiones del Estudio.

Finalmente se agregan 3 anexos y un apéndice. El primero extracta y traduce

del documento de [Schwabe&Vilain99], herramienta de modelado que se utiliza para
representar las interacciones en la navegación de una sitio web. El segundo presenta
el Diccionario de Datos del DER Integrado que se obtuvo en el capítulo 5. El tercer
anexo presenta los datos utilizados para elaborar las aplicaciones del capítulo 7. El
apéndice es el modelamiento del sitio web www.marraqueta.cl, que se ha utilizado en
el estudio.
 12

2. ¿Por qué modelar conceptualmente un sitio

web?
Los modelos se crean para lograr un mejor entendimiento de un ente a repre-
sentar; si el modelo busca representar un ente que existe, será descriptivo y si el en-
te no existe, será un modelo prescriptivo.

En fases iniciales del desarrollo de sistemas, específicamente en la fase de

Análisis, se deben crear los modelos conceptuales del sistema. Según [Høydals-
vik&Sindre93], estos modelos deben describir el problema y los requerimientos de los
usuarios, considerando que en una etapa posterior de diseño se construirán los mo-
delos que entreguen la solución que satisfaga los requerimientos de los usuarios y el
problema planteado. Durante el análisis, el analista debe poner especial atención en
el dominio del conocimiento, objetivos, requerimientos y entorno del sistema, es de-
cir, debe “orientarse al problema” y no limitarse a modelar la solución al problema. De
esta forma se facilita el modelamiento y la validación por parte de los usuarios.

Los modelos creados hacen uso de notación gráfica que representa principal-
mente la información, los procesos y el comportamiento del sistema. Esto puede
complementarse con texto, ya sea en lenguaje cotidiano o especializado.

Según [Pressman98], pág. 190, los principales roles de los modelos son:

• Ayudar al analista a entender la información, la función y el comportamiento

del sistema, haciendo por tanto más fácil y sistemática la tarea de analizar re-
querimientos.

• Convertirse en el punto de comparación entre lo logrado y lo planificado.

• Fundamentar el diseño, proporcionando al diseñador una representación lógi-

ca, o esencial, de la implementación.

Por otro lado, las aplicaciones web están llegando a ser más y más populares.
Esto, en parte, debido al rápido progreso de herramientas y tecnologías para des-
arrollarlas. Además, debido a que los diseñadores de sistemas están reconociendo
que hay situaciones donde las aplicaciones web tienen ventajas significativas con
respecto a las aplicaciones tradicionales.

Según [Conallen00], hasta la fecha, el foco de desarrollo de aplicaciones web

han sido las herramientas y se ha prestado poca atención al proceso del desarrollo.

Los ambientes actuales del desarrollo facilitan la producción de aplicaciones

web simples, lo que tiene el efecto secundario de impulsar a los desarrolladores a
 13

que construyan aplicaciones sin el adecuado análisis y diseño. Esto a la larga trae
diversos problemas si se piensa que cualquier sistema con complejidad no trivial ne-
cesita ser diseñado y ser modelado.

Por lo tanto, si se está en presencia del desarrollo de un sitio web de comercio

electrónico, se puede fundamentar la necesidad de modelar con dos argumentos
complementarios: modelar un sitio web para ayudar a manejar la complejidad de un
sistema, por una parte, y para aumentar la satisfacción y lealtad de los clientes, por
otra, basándose por ejemplo en CRM.

2.1 Modelar para mejorar la calidad del sistema

[Conallen00] destaca la importancia de modelar un sitio web para ayudar a

manejar la complejidad de un sistema. Además, las aplicaciones en web pueden
transformarse en aplicaciones complejas rápidamente.

Se debe considerar también, que un mismo sistema se puede representar por

distintos modelos consistentes entre sí. Cada modelo tiene un propósito específico,
con un nivel distinto de abstracción para distintos usuarios.

Partiendo de la base que el elemento básico de un sitio web es la página web,

la página debe ser modelada. [Conallen00] propone utilizar UML para representar
una página como un objeto, con las propiedades de tal objeto: fuentes, tablas, texto,
etc.; y los scripts de la página se representarían como métodos de un objeto página.

Por otra parte [Deboni99] argumenta que se deben modelar las aplicaciones
en web, principalmente debido a que las aplicaciones en web están aumentando ca-
da vez más, en cuanto a:

• Cantidad: proliferación de intranets, extranets y de e-commerce.

• Complejidad: en un principio se construyeron sitios estáticos, posteriormente

se elaboraron sitios dinámicos y actualmente están en auge las aplicaciones
en web1.

• Importancia: Los negocios pasan a depender de las aplicaciones en web.

1
La distinción entre sitio web y aplicación en web, según [Conallen00], es que un sitio web
en donde el usuario entra (navegación a través del sitio e ingresa datos) y modifica los esta-
dos del negocio (más allá por supuesto de registros del acceso y de contadores). Mientras
que una aplicación de web utiliza un sitio web como medio para una función más típica.
 14

Además, modelar una aplicación web permite mejorar la calidad del sistema,
ya que se detectan los errores y se proponen soluciones antes de implementar el
sistema; gestionar el proceso de evaluación del sistema; y apoyar la evolución y el
crecimiento de la aplicación, ya que existe documentación y se realiza un mayor es-
fuerzo para entender y modelar el problema.

Por otra parte, un modelo ayuda a los desarrolladores antes y después de

construirlo, ya que permite:

Antes de construir:

• Proyectar la aplicación, dimensionando los recursos y plazos de su desa-

rrollo con mayor certeza.

• Evaluar la viabilidad técnica de un proyecto.

• Analizar alternativas de implementación.

• Seleccionar arquitecturas de soluciones.

Después de construir:

• Evaluar el proyecto y corregir errores.

• Dimensionar recursos y plazos para la mantención.

• Para cambiar la plataforma.

• Para actualizar la arquitectura.

Además, [Deboni99] propone que en la elaboración del modelo participen in-

tegradamente los analistas del negocio, los proyectistas, los diseñadores y los web-
masters.

2.2 Modelar para mejorar la relación con los clientes

Siempre aparecen nuevos modelos de negocios que pretenden maximizar las

ganancias de las empresas, utilizando para ello nuevos conceptos y enfoques, algu-
nos de los cuales dan buenos resultados y otros no, hasta que el tiempo lo demues-
tra. Uno de estos modelos de negocios actuales se ha asociado al concepto de CRM
aunado al impresionante desarrollo de Internet.

CRM o Customer Relationship Management es un proceso por el cual se en-

focan las acciones de una organización hacia la satisfacción y lealtad de los clientes.
 15

Andrés Vargas, citado por [González00], define a CRM como “un proceso que posibi-
lita reorientar los mecanismos estratégicos empresariales desde la visión centrada en
el producto hacia una perspectiva referida a la figura del cliente y su relación con la
empresa, proceso por el cual la empresa maximiza la información de la que dispone
acerca de sus clientes con el fin de incrementar su conocimiento acerca de ellos y
construir a partir de tal conocimiento relaciones altamente rentables y duraderas con
aquellos segmentos de la población de clientes que mayor rentabilidad puedan pro-
porcionar a la empresa”.

Según esta definición, las empresas que tradicionalmente han enfocado sus
esfuerzos en productos, ahora reconocen la importancia del cliente como el elemento
más importante en las relaciones comerciales. Con el auge de Internet y las facilida-
des que ésta presenta, se han creado empresas que desde sus inicios se enfocan en
las necesidades de los clientes.

Según distintos autores, el proceso de CRM consta de cuatro etapas principa-

les, que tal como muestra la figura 2.1, obedecen a un orden natural y cuyo objetivo
es tratar clientes diferentes de una manera diferente, estas etapas son:

1. Identificar: Consiste dar a conocer el sitio web, lograr que los visitantes se
identifiquen con el sitio, en conocer a cada cliente y su historia, de forma indi-
vidual.

2. Diferenciar: Cuantificar el valor neto presente de las utilidades de una rela-

ción futura del cliente individual con la organización. Para encontrar los clien-
tes de mayor valor real y los clientes de mayor potencial o valor estratégico y
los clientes sin probabilidad de utilidad.

3. Interactuar: Durante esta etapa, se busca conocer cada vez más a los clien-
tes y sus necesidades, y así crear una relación de aprendizaje que conlleve a
una personalización de los servicios o productos. Es importante que durante
esta etapa los clientes deben percibir que la organización lo atiende con ex-
clusividad y privacidad.

4. Personalizar: Finalmente, esta etapa, basada en el conocimiento de los clien-

tes, pretende crear una relación individualizada según las necesidades del
consumidor (personalización masiva).

Identificar Diferenciar Interactuar Personalizar

Figura 2.1 – Cuatro etapas de CRM

 16

Desde un punto de vista más general, también puede observarse el CRM

comprendido por tres etapas, que de alguna u otra forma son similares a las anterio-
res, pero corresponden a un enfoque distinto. Estas etapas se muestran en la figura
2.2 y se describen a continuación:

1. Integración: dada la existencia de una serie de fuentes, canales de informa-

ción y departamentos dentro de las organizaciones, el primer paso esta en la
integración de los datos producto de la relación con los clientes. Esta informa-
ción debiera estructurarse en un datawarehouse. Esta etapa permitirá proce-
der con el proceso de análisis y extracción de conocimiento del negocio.

2. Análisis: esta etapa busca, a partir de los datos de los clientes, alcanzar un
conocimiento de las tendencias y patrones de comportamiento que permita
crear un modelo de predicción del comportamiento futuro y establecer indica-
dores que ayuden al soporte de la toma de decisiones. Puede asociarse a un
datamining.

3. Acción: esta etapa es la que da sentido a una estrategia de CRM, pues to-
mando en cuenta los resultados del análisis, es necesario tomar acciones
concretas que pueden afectar desde las estrategias de marketing hasta la or-
ganización propia de la empresa.

Integración Análisis Acción

Datamining E-business
Datawarehouse

Figura 2.2 – Tres etapas de CRM

 17

Como se ha mencionado, el objetivo que busca el proceso de CRM es maxi-

mizar los beneficios de la empresa mediante un conocimiento de los clientes y la re-
lación que se tiene con ellos.

Ninguna técnica por sí sola puede entregar una vista integral de los clientes,
de su comportamiento y de sus características descriptivas. La rentabilidad de los
clientes se puede estimar mediante un análisis global que describa a los clientes.
Esto incluye:

• Segmentación
Esto incluye la subdivisión de la población de clientes en pequeños grupos.
Posteriormente, se realizan campañas de marketing y anuncios específicos
para estos grupos, según sus características.

• Rentabilidad del Cliente

La medición y el ranking de clientes basado en su rentabilidad, típicamente
medido por la acumulación de ingresos basados en la asignación directa de
los costos de los productos, el costo indirecto de adquirir un cliente y los cos-
tos operacionales.

• Retención del Cliente

La probabilidad de que un cliente sea fiel a una empresa.

• Clustering de Clientes
La identificación de características comunes entre un segmento de clientes
que son asociados con un comportamiento o característica específica.

• Análisis de la Respuesta
La medida de efectividad de una campaña de marketing a un segmento espe-
cífico de clientes.

El análisis de CRM no es para hacer las organizaciones más productivas,

aunque esto puede ser un beneficio adicional, el verdadero valor de CRM es que po-
sibilita cambios en las estrategias organizacionales.

El análisis de clientes es esencial para entender los efectos de todas las ca-
racterísticas que contribuyen al comportamiento de los clientes.

Además, CRM puede generar una serie de beneficios a las empresas tales
como:

• Aplicación de marketing uno a uno, diferenciado por tipos de cliente.

• Establecimiento de una relación personalizada que genere mayor lealtad.

 18

• Los presupuestos destinados a marketing se hacen más rentables ya que se

dirigen a los segmentos de clientes que se sabe pueden dar una respuesta
positiva, y se reduce el gasto en campañas masivas.

• Se busca la lealtad de los clientes actuales así como atraer nuevos clientes.

Por otra parte, algunos autores han estado desarrollando el tema de la asocia-
ción entre Internet y el CRM, dándole diversos nombres, entre ellos: IIM (Internet In-
teraction Management), ICRM (Internet Customer Relationship Management), IRM
(Internet Relationship Management) o e-CRM (electronic CRM); todos estos acróni-
mos tienen un significado similar y un mismo objetivo: lograr la satisfacción y mejorar
la calidad de las interacciones con los clientes, todo a través de Internet. Es acá don-
de Internet se destaca como uno de los medios de interacción con los clientes, así
como lo son el teléfono, el correo y el contacto personal.

Puede considerarse a Internet como un medio de comunicación para llegar a

los clientes, pero con la ventaja de que no sólo comunica al igual que lo hace un pe-
riódico o la televisión, sino que permite interactuar y transferir información en dos ví-
as, tanto desde la empresa a los clientes como desde los clientes a la empresa; esto
da lugar a la interacción. Además, Internet aprovecha la funcionalidad de sus herra-
mientas como el e-mail y el chat, para llegar a establecer una relación con los usua-
rios. Todo esto es ideal para un proceso de CRM, pues Internet le brinda la facilidad
de obtener los datos de los clientes de una forma muy ágil, por ejemplo, este es el
caso de aquellas páginas electrónicas que solicitan cierta cantidad de datos para te-
ner acceso a la información contenida en una página web.

Las interacciones con los clientes que ocurren a través de Internet aplican
idealmente con el proceso de CRM, ya que permiten la utilización de una plataforma
tecnológica para el diseño, desarrollo e implementación de técnicas de administra-
ción de información como el datawarehousing y el datamining, los cuales permiten
pasar fácilmente de la etapa de integración, mencionada antes, a la etapa de análi-
sis; asimismo, estas técnicas se pueden combinar con herramientas de e-
business para asociar las interacciones a través de Internet con el valor económico
actual y futuro de los clientes.

Por otro lado, las tecnologías asociadas a Internet tienen la facilidad de aso-
ciarse, al back-office y a través de sistemas de información, donde se procesan con-
sultas, observaciones y quejas de los clientes, lo cual se integra en una base de da-
tos para su posterior análisis.

Otro punto a señalar es que a través de la Internet se logra uno de los objeti-
vos fundamentales de CRM, como lo es la personalización de los servicios o produc-
tos. Dentro de la web pueden encontrarse muchos ejemplos donde el consumidor
 19

puede dar las especificaciones de los productos y servicios de acuerdo con sus gus-
tos y preferencias, antes de adquirirlos.

Las ventajas evidentes de la utilización de Internet pueden señalarse de ma-

nera puntual:

• Disponibilidad: 24 horas al día, 7 día a la semana, 365 días al año.

• Bajo costo.
• Audiencia potencial amplia.
• Posibilidad de automatizar procesos asociados.

Se puede concluir entonces, que Internet es una herramienta sumamente im-

portante para CRM ya que puede habilitar de una manera muy eficiente y eficaz las
etapas de integración y análisis de datos, quedando a quienes toman las decisiones
la última etapa que constituye el tomar acciones concretas basadas en el análisis de
datos. Además, la utilización de Internet para la obtención de datos de los clientes, y
el análisis de los mismos, permite aumentar la eficiencia y eficacia del proceso de
CRM.

Otro aspecto a considerar, es que en los últimos años los consumidores han
descubierto la facilidad de comprar online, y rápidamente comienzan a incrementarse
las ventas por este canal. Sin embargo, colocar productos para ser vendidos a través
de la web no asegura que una compañía pueda capturar este mercado en crecimien-
to.

A su vez, el que los consumidores gasten su dinero a través de Internet, pro-

duce que se incrementen sus expectativas de recibir un mejor servicio. De esta for-
ma, la web no debe considerarse sólo como un canal de venta o entrega, sino que,
además, como el canal primario de servicio a clientes.

Según [Manzano00], actualmente numerosos clientes se encuentran descon-

tentos con el nivel de servicio que reciben en el canal online. Están cansados de
completar difíciles formularios y buscar las respuestas a las preguntas que se les
plantean sobre productos o servicios. Los clientes quieren respuestas a sus consul-
tas sobre productos o servicios y cada día aumenta el número de personas que de-
sean respuestas en tiempo real, utilizando facilidades como chat o teléfono, mientras
que otros prefieren recibir las respuestas vía e-mail.

Hace algunos años, la mayoría de los esfuerzos de servicio al cliente, eran di-
rigidos vía teléfono o correo directo. Los call centers utilizaban números libres de pa-
go, sistemas de respuesta interactivos por voz (IVR) y tecnología de distribución au-
tomática de llamadas (ACD). Los departamentos de servicio al cliente se medían te-
niendo en cuenta la productividad.
 20

Posteriormente, los call centers funcionaron utilizando números 600 (costo de

llamada local) y sistemas ACD e IVR. Listas estáticas de preguntas frecuentes
(FAQs), aplicaciones de búsqueda y autoservicio, son funcionalidades basadas en
Internet que se utilizan para presentar opciones de autoservicio a clientes en la web.
La funcionalidad del e-mail, asíncrono al servicio a clientes, se usa para interactuar
con los representantes del servicio a clientes (CSR por Customer Service Relations-
hip), los que a su vez, de forma manual, responden las preguntas de los clientes. Sin
embargo, el servicio a clientes basado en la web no está conectado con el resto de la
compañía.

Actualmente, se ofrece comunicación en tiempo real y sobre múltiples canales.

Los servicios basados en teléfono permanecen, aún siendo éstos un método muy
costoso de servir a un cliente. Se utilizan sistemas basados en bases de datos de
conocimiento para enviar de forma automática fax o e-mail de respuesta a consultas
de clientes. Sistemas basados en la web, como instant messaging, whiteboarding,
voz sobre IP, chat y video, permiten a los clientes comunicarse con el CSR mientras
se encuentran frente a su computador personal. Las facilidades de chat les propor-
cionan una experiencia continua que no requiere la utilización del teléfono. Además,
facilita que el mismo CSR pueda gestionar múltiples contactos de forma simultánea.
El CRM de la compañía está totalmente conectado, permitiendo la recopilación de
datos y que éstos se compartan a través de múltiples canales.

Cuando se implementa un sitio de e-commerce o el de una compañía, en oca-

siones, el concepto de servicio al cliente se pasa por alto y/o no se toma en cuenta.
No obstante, los clientes esperan que la calidad del servicio que van a recibir exceda
las experiencias anteriores. Lograr esto -partiendo de dicha situación-, se convierte
en una realidad cara para cualquier organización y es muy complicado ponerlo en
funcionamiento de una forma rápida.

Por otra parte, para llevar a cabo la implementación de un e-business, [Kala-

kota&Robinson00] describen tres focos de excelencia en los cuales se puede basar,
estos son: excelencia en el servicio, excelencia operacional y excelencia en la inno-
vación continua.

1. Excelencia en el servicio: Entregando lo que quieren los clientes con servicio y

valor superiores. Para esto, se deben elegir nichos específicos con clientes de al-
to valor y servirlos bien.

Los principios que operan en la excelencia en el servicio son:

• Preparar a la Organización para lo imprevisto: maniobrabilidad y flexibilidad.

• Recolectar y mantener información actualizada, precisa, oportuna y donde se

necesite.
 21

• Administrar el contacto con el cliente (CRM): anticipándose a sus necesida-

des, compartiendo información para proveerle expedito autoservicio si el clien-
te lo desea.

• Desarrollar una cultura organizacional sobre el servicio al cliente.

2. Excelencia operacional: Entregando productos de alta calidad, sin errores y por

un precio razonable. Se deben entregar productos y servicios al menor costo mi-
nimizando los problemas para el cliente.

Los principios que operan en la excelencia operacional son:

• Eficiencia en la valorización de activos: asignación eficiente y al menor costo

posible de los recursos.

• Gestión eficiente de transacciones: mejorando el tiempo de respuesta e inte-

grándose con los proveedores.

• Gestión de inteligencia de ventas: conocimiento en tiempo real de la informa-

ción requerida para realizar cualquier venta.

• Medición del desempeño de los procesos

• Gestión de las expectativas de los clientes: bajo el compromiso de variedad

v/s eficiencia.

3. Excelencia en la innovación continua: Entregando productos y servicios que

superen límites y agraden al cliente. Requiere dedicación para ofrecer continua-
mente beneficios y características por sobre los competidores.

Los principios que operan en la excelencia en la innovación continua son:

• Estilo de gestión orientado al riesgo: para ser líderes e innovadores se debe

asumir que la innovación conlleva riesgos propios de las nuevas ideas.

• Crecimiento por medio de fusiones o adquisiciones.

• Educación para el mercado: debe educarse a los consumidores acerca de los

beneficios que tienen los nuevos productos o servicios la organización les en-
trega.

• Incentivo a la innovación: se debe recompensar la experimentación mediante

sistemas de compensación para incentivar la innovación.
 22

Por lo tanto, se puede decir que al decidir que se va a desarrollar un sitio de

comercio electrónico, hay que partir del supuesto que a los clientes se les debe aten-
der de la mejor manera posible, porque sino, la probabilidad de tener éxito es muy
escasa.

Cada uno de estos enfoques de excelencia en los cuales se puede basar un e-

business, pone énfasis en distintos aspectos del modelo de sitio web que se utilice,
en el siguiente capítulo se modela la navegación en un sitio web de comercio elec-
trónico, para posteriormente registrar información de los clientes y utilizarla para me-
jorar la relación con ellos.
 23

3. Esquema Navegacional
En [Schwabe&Vilain99] se presenta la notación de la metodología OOHDM
(Object-Oriented Hypermedia Design Method), que modela conceptualmente un sitio
web utilizando UML (Unified Modeling Language) y propone un modelo complemen-
tario para representar el modelamiento navegacional, que se basa principalmente en
el respectivo Diagrama de Clases.

Debido a que UML no trata el modelamiento navegacional, se desarrolla la no-

tación del esquema navegacional basándose en UML.

Tal como se explicó anteriormente, esta metodología se basa principalmente

en la Orientación a Objeto utilizando UML, ya que el Diagrama de Clases es la base
del modelo que representa la estructura navegacional.

Como el Esquema Navegacional se sustenta en las características estructura-

les del Diagrama de Clases -y no en sus características funcionales, como podrían
ser las operaciones- y bajo el supuesto que todas las Clases representadas en el
Diagrama de Clases son persistentes, es posible adaptar también a un Diagrama
Entidad Relacionamiento y, de esta forma, modelar la estructura navegacional sin
tomar decisiones de implementación aún, es decir, tener la factibilidad de implemen-
tar el sistema bajo el paradigma de la Orientación a Objeto o fuera de él.

En el Apéndice 1 se presenta un Problema resuelto del Sistema de Ventas

On-Line www.marraqueta.cl [Bustos&Jaar99]. El sistema, entre otros aspectos rele-
vantes, debía apoyar a los clientes y ser de fácil navegación, debía ofrecer distintas
opciones y permitir monitorear el estado de avance de su pedido hasta su despacho.
Los productos comercializados son videos, CD’s y libros.

A continuación, en la figura 3.1, se presenta el Diagrama Entidad Relaciona-

miento que representa la estructura del mencionado sitio.
 24

Empresa

(t, e)

(1, n) (1, n) (1, 1)

clasifica- provisión Proveedor Courier
Categoría
ción

(1, 1)
(1, n)

pertenen- (0, n) (0, n) (1, n) (1, n)

Cesta contenido Producto
cia

(t, e)
inclusión
(0, 1)

(1, 1) Cd Libro Video

Cliente
servicio

(0, n)

Cliente (0, n)
solicitud Pedido
Registrado

(t, e) (0, n)

(1, 1) consigna-
Flete
ción
Cliente Cliente
Eventual Permanente

Flete Expreso
(1, n)

Figura 3.1 – Diagrama Entidad Relacionamiento del Sitio www.marraqueta.cl [Bustos&Jaar99]

 25

De acuerdo a los ejemplos analizados en [Rossi00], [Schwabe&Vilain99] y

otros, se puede inferir que generalmente las navegaciones que debe realizar un visi-
tante para encontrar una instancia de una determinada Clase o Entidad se pueden
clasificar en tres grandes tipos:

1. Buscando directamente la instancia en la Clase o Entidad a la que ella perte-

nece.

2. Buscando a través de las Clases o Entidades relacionadas directamente con

la buscada.

3. Buscando de acuerdo a características propias del visitante o cliente, que

hayan quedado registradas anteriormente, por ejemplo: cesta de compras, or-
denes anteriores, lista deseada, etc.

Además, se puede agregar que la alternativa que escoja el visitante para bus-
car una determinada instancia de alguna clase o entidad, dependerá de su grado de
conocimiento en la utilización de aplicaciones en web, conocimiento del sitio, cono-
cimiento de lo que se quiere, tipo de compra que desea realizar, etc.

3.1 Criterios de Búsqueda

A partir del Diagrama presentado en la figura 3.1 y de la descripción del pro-

blema, presentado en el Apéndice 1, se pueden determinar algunos criterios de bús-
queda que el sitio debiera ofrecer, tales como:

• Búsqueda directa del producto requerido: Este tipo de búsqueda

asume que el visitante conoce el sitio y sabe lo que quiere comprar.

• Búsqueda a través de productos relacionados: Esta búsqueda la

realizarían visitantes que conocen o no el sitio, pero que no saben bien
lo que desean comprar, es decir, tienen una idea del producto que de-
sean, o bien, del tema (o concepto) que les interesa, pero no tienen cla-
ro que es lo que el sitio les puede ofrecer para sus requerimientos.

• Búsqueda personal: Este tipo de búsqueda supone que el visitante ha

realizado búsquedas o compras anteriores en el sitio y que se ha regis-
trado, por lo tanto puede buscar lo que dejó en su cesta de compras, o
productos relacionados con sus compras anteriores, etc.

Si se consideran los tipos de búsqueda mencionado anteriormente, se puede

realizar una primera categorización de las Entidades representadas en la figura 3.1.
En la figura 3.2 se presentan ennegrecidas las Entidades que debieran asociarse al
esquema navegacional.
 26

Empresa

(t, e)

(1, n) (1, n) (1, 1)

clasifica- provisión Proveedor Courier
Categoría
ción

(1, 1)
(1, n)

pertenen- (0, n) (0, n) (1, n) (1, n)

Cesta contenido Producto
cia

(t, e)
inclusión
(0, 1)

(1, 1) Cd Libro Video

Cliente
servicio

(0, n)

Cliente (0, n)
solicitud Pedido
Registrado

(t, e) (0, n)

(1, 1) consigna-
Flete
ción
Cliente Cliente
Eventual Permanente

Flete Expreso
(1, n)

Figura 3.2 – Diagrama Entidad Relacionamiento asociado a la Navegación

Tal como se muestra en la Figura 3.2, las Entidades relacionadas directamen-

te con la Entidad Producto, son: Pedido, Proveedor, Cesta y Categoría, por lo tanto,
según el criterio expuesto anteriormente, si a este conjunto le agregamos la Entidad
Cliente, que aunque no se relaciona directamente con la Entidad Producto, sí es re-
querida para las “búsquedas personales”, se puede determinar que estas Entidades
deben aparecer en el esquema navegacional.

3.2 Resumen de OOHDM

A continuación se explica brevemente la notación de la metodología OOHDM

para efectos de tener un primer acercamiento antes de continuar, ya que es explica-
da en detalle en el Anexo 1. Esta notación está fuertemente basada en UML, para
realizar el modelamiento conceptual y analizar el dominio de la aplicación que será
desarrollada se construyen Diagramas de Clases y otros modelos de UML. Sin em-
bargo, debido a que UML no emplea el concepto de contexto navegacional, es decir,
 27

el conjunto de circunstancias que permiten la navegación, se desarrolla la notación

del esquema navegacional.

El Esquema navegacional se desarrolla a partir del Diagrama de Clases, como

el que se presenta en la figura 3.3, definiendo perspectivas de acuerdo con cada tipo
de usuario.

1...* 1...* 1...* 1 0.. Material del

Módulo Curso
Curso
tiene 4 tiene 4
1 Nombre: String Título: string
Programa: Texto Resumen:texto
Horas semanales: Real Indice: texto
es organizado en
Temas: lista de <nombre:string>
guarda_ftp ()
Profesores:lista de
1...* mostrar ()
<nombre:string>
Institución: string
Calendario semanal e-mail:string
curriculum: texto
Fecha_inicio: Fecha
Fecha_fin: Fecha recomendar (autor, contenido)
Actividades: Array [2,7] of Text

1...*
Coordinador
3 es enrolado en
Nombre: String
e-mail: String
MóduloEvaluación: Texto

Figura 3.3 – Ejemplo de Diagrama de Clases

Un contexto navegacional es un conjunto de objetos, de una o varias clases,

que están relacionados de acuerdo con algún aspecto. Como ejemplos de contextos
navegacionales se pueden citar: todos los coordinadores de un módulo, los profeso-
res de una determinada área de investigación, el material de estudio de un curso, los
profesores de estudiantes que practican un determinado deporte, etc.

Un contexto es representado por un rectángulo con un identificador. Los con-

textos son colocados dentro de otro rectángulo sombreado, que representa la clase
navegacional de sus elementos, el identificador de esta última se muestra con letra
cursiva.

Generalmente el acceso a los elementos de un contexto es hecho a través de

un índice. Los índices son representados por rectángulos de líneas discontinuas
gruesas. Los índices exclusivos para el acceso a los elementos de una clase en de-
terminado contexto poseen como identificador el nombre de clase en plural. Por
ejemplo, el índice para acceso a los elementos de clase “módulo” en el contexto
“módulo por materia” es denominado “materias”.
 28

Un contexto de navegación también puede ser formado por los elementos re-
sultantes de una consulta realizada en el momento de la navegación. Los parámetros
de consulta pueden ser definidos automáticamente por el sistema o interactivamente
por el usuario. La figura 3.4 presenta un contexto donde la consulta es realizada en
la clase “Módulo” con una palabra clave como parámetro, a partir de las clases “Mó-
dulo por palabra clave”. El índice de acceso a un contexto por consulta debe presen-
tar una barra vertical ennegrecida al lado derecho, indicando que la entrada es de-
terminada durante al navegación (índice dinámico).

Un contexto puede ser dinámico o no. Un contexto de navegación dinámico es

aquel cuyos elementos son definidos o alterados durante la navegación y es repre-
sentado por un rectángulo con una barra vertical ennegrecida al lado derecho.

Módulo

Materias: Módulos Por Materia

Módulos por palabras

claves <por nombre,
Menú principal Por Palabra clave
materia, objetivo y/o
programa>

Módulos por coordinador Por Coordinador

Figura 3.4 – Contexto de navegación por consulta

Un contexto de una clase puede encontrarse a partir de la consulta de un con-

texto asociado a la misma u otra clase. En muchos casos, es interesante permitir
que, cuando un objeto pertenece a más de un contexto de navegación, sea posible
moverse de la navegación para ocurrir dentro de otro contexto al cual el objeto perte-
nece.

La figura 3.5 muestra una línea discontinua separando los contextos, ésta re-
presenta que no es posible navegar a partir de un elemento de un contexto para el
otro contexto. Cuando la línea no es presentada, es posible navegar a partir de un
contexto para cualquier otro contexto.
 29

Módulo

Por Materia
Menú principal

Por Palabra clave

Curso

Módulos por
Por Coordinador Por Módulo
coordinador

Por Materia

Figura 3.5 – Consulta de contextos de distintas clases

Una clase navegacional también puede presentar un contexto de creación,

modificación o eliminación de sus instancias. Por ejemplo, una aplicación puede
permitir, durante su ejecución, la inclusión de un coordinador en un determinado mó-
dulo, esto se presenta en el contexto dinámico “creación” de la figura 3.6.

La creación de una instancia u objeto está representada por un rectángulo con

bordes redondeados y una barra vertical del lado derecho. Cuando una clase posee
un contexto de creación, modificación o eliminación, los otros contextos, a pesar de
ser dinámicos, no precisan presentar una barra vertical ennegrecida al lado derecho.

La elipse negra asociada al lado izquierdo del contexto “creación” indica que el
acceso a ese contexto está protegido, o sea, solamente usuarios autorizados podrían
accesarla.

Coordinador

Por Módulo

Menú principal Creación

Figura 3.6 – Contexto de creación

Finalmente, se presenta el contexto asociado al diagrama de clases presenta-

do en la figura 3.3.
 30

Módulo

Materias: Módulos Por Materia Material del Curso

Por Curso
Módulos por palabras
claves <por nombre,
Menú principal Por Palabra clave
materia, objetivo y/o
programa>
Curso

Módulos por coordinador Por Coordinador Por Módulo

Por Materia
Coordinador
Calendario Semanal
Por Módulo
Por Módulo

Creación

Asignaturas: Cursos

Figura 3.7 – Ejemplo del Esquema Navegacional asociado

3.3 Adaptación de OOHDM al DER

Aunque la metodología OOHDM, y en particular el Esquema Navegacional,

está basada en la orientación a objeto, se puede adaptar para construir el Esquema
Navegacional a partir del Diagrama Entidad Relacionamiento, en vez de construirlo a
partir del Diagrama de Clases, como se propone originalmente. Todo esto bajo el
supuesto que todas las Clases representadas en el Diagrama de Clases son persis-
tentes y que, por lo tanto, es posible construir un Diagrama Entidad Relacionamiento
que represente lo mismo que representa el Diagrama de Clases.

La figura 3.3, muestra el Diagrama de Clases asociado el Esquema Navega-

cional de la figura 3.7.

Según [deChampeaux94], un objeto “es identificable, tiene características que

alcanzan un estado local, tiene operaciones que pueden cambiar el estado del siste-
ma local, además de inducir operaciones en sus pares”. Por lo tanto, según esta de-
finición, la principale diferencia que se puede establecer entre un objeto y una enti-
dad es que el primero tiene atributos y operaciones, mientras que la última sólo tiene
atributos. A esto, debe agregarse que una entidad es por definición persistente,
mientras que una clase puede o no ser persistente.

Si se aplican estas definiciones y diferencias al DC y DER, y se relacionan con

el Esquema Navegacional, se puede inferir que deben existir ciertos comportamien-
 31

tos u operaciones de los objetos que son utilizados o activados por los visitantes
mientras navegan.

Un ejemplo claro de esto son los índices dinámicos. Otros serían, la posibili-
dad que tienen los visitantes de crear una instancia, o bien, la protección para que
solamente usuarios con permiso pudieran accesar ciertas clases, tal como lo muestra
la figura 3.6. Ambos comportamientos pueden asociarse a las clases respectivas,
pero de ninguna forma podrían asociarse a las entidades del DER. Por lo tanto, si se
modela fuera del paradigma de la orientación a objeto, estos comportamientos debe-
rían ser realizados por procesos del sistema, independientes de las clases.

Otros problemas más complejos, serían que determinadas clases de objetos,

tuvieran operaciones encapsuladas, es decir, operaciones que sólo ellos pueden ac-
tivar, ya que por su definición, estas operaciones no podrían realizarse por el siste-
ma; o que el Diagrama de Clases incluya clases no persistentes, las que no podrían
representarse en el Diagrama Entidad Relacionamiento.

Por lo tanto, una variación que debiera realizarse al Esquema Navegacional

original, es la representación explícita de los procesos que deben realizarse cada vez
que el visitante quiere navegar o buscar algo en el sitio. Esta representación puede
ser con círculos de color, como se muestra en la figura 3.8.

Módulo

Materias: Módulos Por Materia Material del Curso

Por Curso
Módulos por palabras
claves <por nombre,
Menú principal Por Palabra clave
materia, objetivo y/o
programa>
Curso

Módulos por coordinador Por Coordinador Por Módulo

Por Materia
Coordinador
Calendario Semanal
Por Módulo
Por Módulo

Creación

Asignaturas: Cursos

Procesos asociados a las

consultas y creaciones

Figura 3.8 – Esquema Navegacional modificado

 32

De esta forma se puede construir el Esquema Navegacional de

www.marraqueta.cl a partir del Diagrama Entidad Relacionamiento de la figura 3.2. El
esquema resultante, utilizando las notaciones explicadas, es presentado en la figura
3.9.

Comentarios

Por Productos

Producto

Propiedades similares por Propiedades

Categorías
relacionado
Categorías
Categorías Productos
por Referencias

Búsqueda
Búsqueda
por Búsqueda

Menú principal Cesta

Cesta Productos en la
en la cesta
cesta
Pedido
Pagar Formulario de
en Pedido
Pedido

Cliente
Cuenta Cliente
Consulta Ordenes
Cuenta anteriores

Figura 3.9 – Esquema Navegacional de www.marraqueta.cl

Tal como se puede visualizar en la figura 3.9, todas las Entidades relaciona-
das directamente con la Entidad Producto aparecen en el Esquema Navegacional.
Además, como se puede observar, en la figura 3.9, aparece otra entidad que no exis-
te en el DER de la figura 3.2, esta es la Entidad Comentarios. En estricto rigor, esta
Entidad no puede aparecer en el Esquema Navegacional si no existe en el DER res-
pectivo, por lo que si se requiere que aparezca en el Esquema debiera modelarse
también en el DER como otra entidad y no como atributo de la Entidad Producto. Los
procesos asociados a las búsquedas y validaciones son representados por círculos
celestes, tal como se planteó anteriormente.
 33

4. Diagrama Entidad Relacionamiento Integrado

Como se ha planteado anteriormente, uno de los objetivos específicos de esta
investigación es registrar las interacciones de los visitantes con el sitio web, para me-
jorar las relaciones con el sitio.

4.1 DER asociado al Esquema Navegacional

El Esquema Navegacional del sitio presentado en la figura 3.9 representa las

interacciones del sitio con un visitante, si se construye un Diagrama Entidad Relacio-
namiento que registre estas interacciones se puede obtener el DER presentado en la
figura 4.1.

Cesta de
productos Pedido
Sesión
realizado

(0,n)
(1,1) (0,n)
tiene
productos
realiza consulta
ingresados a

(1,1) (0,n)
(1,1)

Visitante en (0,n) busca a (0,n)

línea través de

(0,n)
Palabra clave
(0,n)

(0,n)
utiliza consulta

(0,n) (0,n)
obtiene

Criterio de
Consulta (0,n)
búsqueda por
producto
categorías

(0,n) asociados (0,n) Resultado de

a la búsqueda

Figura 4.1 – DER asociado el Esquema Navegacional

 34

De esta forma, se obtiene un modelo que pretende registrar las interacciones

del visitante con el sitio sin que el visitante tenga que completar encuestas o respon-
der preguntas.

4.2 Asociaciones entre Entidades de ambos DERs

Si se observa la figura 4.1, todas las relaciones de la Entidad Visitante en Lí-

nea son tomadas a partir de las posibilidades de búsqueda que se presentan en el
Esquema Navegacional de la figura 3.3, excepto la Entidad denominada Sesión, ya
que esta Entidad es una característica asociada al visitante, que se registra porque
puede servir también para mejorar las relaciones con ellos, por ejemplo: registrando
el idioma que se utiliza desde ciertas conexiones, la hora local, hora de inicio de la
sesión, hora de término, etc.

Una pregunta que nace a continuación es cómo se relacionan, si es que existe

relación, el DER operacional mostrado en la figura 3.1 y el DER asociado el Esque-
ma Navegacional mostrado en la figura 4.1.

Rápidamente se pueden vislumbrar asociaciones o relaciones entre algunas

Entidades de un modelo con Entidades del otro. La figura 4.2 muestra las relaciones
entre Entidades de ambos modelos.

Empresa

(t, e)

(1, n) clasifica- (1, n) (1, 1)

Categoría provisión Proveedor Courier
ción

(1, 1)
(1, n)

pertenen- (0, n) (0, n) (1, n) (1, n)

Cesta contenido Producto
cia

(t, e)

Cd Libro Video
inclusión
servicio

Sesión
(0, n)

(0, n) (1,1)
solicitud Pedido Pedido
realizado

(0, 1) (0, n) (0,n)

(1, 1) consigna-
Cliente Flete realiza consulta
(1, 1) ción

(1,1) (0,n)

Cliente Flete Expreso Visitante en (0,n) busca a (0,n)

Registrado (1, n) (1,1) línea través de
(0,n)
(t, e) tiene (0,n)
productos Palabra clave
ingresados a utiliza

consulta (0,n)
Cliente Cliente
(0,n) (0,n)
Eventual Permanente
Criterio de (0,n) obtiene
búsqueda por
categorías
Cesta de Consulta (0,n)
productos producto

(0,n) asociados (0,n) Resultado de

a la búsqueda

Figura 4.2 – Asociaciones entre Entidades de ambos DERs

La figura 4.3 muestra estas asociaciones en un Diagrama más simplificado, en
que no se presentan todas las Entidades, sino sólo las que tienen alguna relación.
 35

(1, n) clasifica-
Categoría (1, n) (1, 1)
ción provisión Proveedor

(1, n)

(0, n) (1, n) (1, n)

Cesta contenido Producto inclusión

(0, n)

pertenen-
cia

(0, 1) (0, n) Pedido

realizado
(1, 1) (0, n)
Cliente solicitud Pedido
(0,n)

(1,1) consulta
Sesión realiza
(0,n)
(1,1)

Visitante en (0,n) busca a (0,n)

(1,1) línea través de
(0,n)
tiene (0,n)
productos Palabra clave
ingresados a utiliza
(0,n)
consulta
(0,n) (0,n)

Criterio de (0,n)
obtiene
búsqueda por
categorías
Cesta de Consulta (0,n)
productos producto

(0,n) asociados (0,n) Resultado de

a la búsqueda

Figura 4.3 – Asociaciones entre Entidades de ambos DERs

 36

4.3 Análisis de las asociaciones entre las entidades

En la figura 4.3 se pueden apreciar asociaciones entre Entidades de ambos

DERs, pero no se especifica cómo son estas asociaciones. A continuación se analiza
qué tipo de asociaciones pueden darse entre las Entidades de DER operacional y del
DER asociado al Esquema Navegacional, para posteriormente analizar las asocia-
ciones del ejemplo en particular.

El DER describe cómo se relacionan los elementos estáticos. Este modelo se

compone de tres piezas claves: las entidades, los atributos que describen a las enti-
dades, y los relacionamientos que conectan las entidades entre sí. Una entidad es la
representación de cualquier composición de información que deba almacenar el sis-
tema, generalmente tiene un gran número de propiedades o atributos diferentes. Una
entidad, a diferencia de un objeto, sólo encapsula datos. Además, en un Diagrama
Entidad Relacionamiento pueden existir tres tipos de asociaciones entre Entidades,
estas son:

• Relacionamientos
• Asociaciones en Jerarquía de Tipos
• Asociaciones en una Entidad Agregada

A continuación se realiza una breve descripción de cada una.

• Relacionamiento: Las entidades se conectan entre sí a través de los relaciona-

mientos. Estos representan las conexiones entre entidades que son relevantes
para el sistema. Cada trío “entidad – relacionamiento – entidad” tiene asociada
una cardinalidad, ésta representa el número mínimo y máximo de ocurrencias de
una entidad (instancia) que se pueden relacionar con ocurrencias de la otra enti-
dad. Generalmente la cardinalidad se expresa como (0,n), (1,1) o (1,n). Se repre-
sentan como rombos en el DER.

• Jerarquía de Tipos: Además, en el Diagrama Entidad Relacionamiento se pue-

den definir Jerarquías de Herencia o Tipos, lo que se realiza a través de relacio-
namientos de subconjunto, donde el conjunto del cual son tomados los subcon-
juntos es denominado padre o súperentidad y los subconjuntos son denominados
hijos o subentidades. Todas las propiedades (o atributos) y relacionamientos del
padre son válidos para sus hijos. Un tipo de entidad puede estar involucrado en
más de una jerarquía de herencia.

• Asociaciones en una Entidad Agregada: En ocasiones es necesario conectar

relacionamientos -que ya conectan a dos entidades- con otro relacionamiento,
como esto no se puede realizar (relacionar dos relacionamientos) se agrega el
conjunto de entidades y relacionamientos, obteniendo una Entidad Agregada, la
que tiene todas las características de una Entidad normal, y teniendo en conside-
 37

ración la consistencia de los atributos e identificadores de las entidades que

agrega.

A continuación se analizan las asociaciones entre las entidades del ejemplo, la

figura 4.4 muestra de mejor forma cuáles entidades se asocian con cuáles.

(1, n) Criterio de (0,n) (0,n)

clasifica-
Categoría búsqueda por utiliza
ción
categorías

(0, n) Pedido (0,n)

inclusión Pedido consulta
realizado

(0, n) (0,n)

solicitud

(1,n) (1,n) (1, 1)

Visitante en
Producto Cliente
línea

(1,n) (0, 1) (1,1)

pertenen-
cia

(0, n)
tiene
(0, n) Cesta de (0,n) productos
contenido Cesta
productos ingresados a

Consulta (0,n)
consulta
producto (0,n)

Figura 4.4 – Asociaciones entre Entidades

En una primera aproximación se puede visualizar que todas las asociaciones
se producen por la intersección entre conjuntos, de lo que se infiere que ambos con-
juntos pueden pertenecer a una misma jerarquía de tipos.
 38

1. Categoría – Criterios de Búsqueda por Categorías

Por una parte están las Categorías registradas en la empresa y por otra están
las categorías por las cuales consultan los visitantes. La relación entre estos
conjuntos puede variar de acuerdo a la forma en que se implemente el motor
de búsqueda a través por categorías. Por ejemplo, si la búsqueda se puede
realizar sólo a través de un conjunto de categorías predeterminado por la em-
presa, entonces ambos conjuntos serían iguales y se deberían fundir las dos
entidades. Por otra parte, si se deja libertad para que los visitantes ingresen
categorías por las cuales desean buscar seguramente existirán algunos que
no estén registradas, en este caso las dos entidades deberían relacionarse
como muestra la figura 4.5, creando dos subentidades, de las cuales una se
relaciona con la entidad del DER operacional. De todas formas, dado que es-
tamos modelando conceptualmente, es decir, independiente de la implemen-
tación que se utilice, entonces la representación más genérica de esta situa-
ción sería la que se muestra en la figura 4.5.

Visitante en
Producto
línea

(1, n)
(0,n)

(1, n) Criterio de (0,n)

clasifica-
Categoría búsqueda por utiliza
ción
categorías

Visitante en
Producto
línea

(1, n)
(1,n)

Criterio de (0,n)
clasifica-
búsqueda por utiliza
ción
categorías

(t,e)

(1, n)

(1,n) se (0,n) Búsqueda Búsqueda no

Categoría
relaciona exitosa exitosa

Figura 4.5 – Asociaciones entre Entidades: Categoría – Criterio de Búsqueda

por Categorías
 39

2. Pedido – Pedidos Realizados

El caso de los Pedidos es distinto, ya que los visitantes sólo podrían consultar
por Pedidos que hayan realizado, por lo tanto, los pedidos por los que se con-
sulta podrían ser un tipo particular de Pedidos, lo que se puede representar
como muestra la figura 4.6.

Visitante en
Producto
línea

(1, n) (0,n)

(0, n) Pedido (0,n)

inclusión Pedido consulta
realizado

Producto

(1, n)

(0, n)
inclusión Pedido
Visitante en
línea

(0,n)

Pedido (0,n)
consulta
realizado

Figura 4.6 – Asociaciones entre Entidades: Pedido – Pedidos Realizados

 40

3. Cliente – Visitante en Línea

Por definición, la Entidad Cliente es un Visitante en línea que compró y se re-

gistró como Cliente, por lo tanto, la mejor representación para esto es la jerar-
quía que se muestra en la figura 4.7.

Visitante en
Cliente
línea

Visitante en
línea

Cliente

Figura 4.7 – Asociaciones entre Entidades: Cliente – Visitante en Línea

 41

4. Cesta – Cesta de Productos

La Cesta es un caso particular, ya que una cesta la crea un Visitante en línea

y esta Cesta es la misma que se representa en el DER operacional, por lo tan-
to, ambas Entidades se deben fundir y representar como una sola. En el caso
que una de ellas pudiera tener más atributos que la otra, éstos debieran agre-
garse a la entidad resultante. La figura 4.8 muestra cómo se representaría la
Entidad Cesta.

Visitante en
Producto
línea

(1, n) (1,1)

tiene
(0, n) Cesta de (0,n) productos
contenido Cesta
productos ingresados a

Visitante en
Producto
línea

(1, n) (1,1)

tiene
(0, n) (0,n) productos
contenido Cesta
ingresados a

Figura 4.8 – Asociaciones entre Entidades: Cesta – Cesta de Productos

 42

5. Producto – Productos

La Entidad Producto es un caso similar a los casos de Entidad Categoría. Ya

que, por una parte están los Productos registrados en la empresa y por otra
están los Productos por los cuales consultan los visitantes. Con un criterio si-
milar al empleado en la Entidad Categoría, resulta como muestra la figura 4.9.

Visitante en
Cesta
línea

(0, n)
(0,n)

(1, n) Consulta (0,n)

contenido Producto consulta
producto

Visitante en
línea
Cesta

(0, n) (0,n)

Consulta (0,n)
consulta
producto
contenido
(t,e)

(1, n)

(1,1) (0,n) Consulta Consulta

Producto contenido producto producto no
existosa existosa

Figura 4.9 – Asociaciones entre Entidades: Producto – Productos

En consecuencia, se puede obtener un modelo Diagrama Entidad Relaciona-

miento que integre el DER operacional y el DER que registra las interacciones de los
visitantes con el sitio. La Figura 4.10, representa el Diagrama Entidad Relaciona-
miento integrado con estas adecuaciones realizadas, se destacan la jerarquías de
tipos generadas con color azul. En el Anexo 2 se presenta el Diccionario de Datos de
este DER.
 43

(0,n) (0,n)
consulta Empresa

asociados (0,n) Consulta

a producto (t, e)

(0,n) (t,e) (1, 1)

Proveedor Courier
Sesión
Resultado de la
búsqueda Consulta Consulta (1, 1)
(1,1) producto no producto
existosa existosa

realiza (0,n) (0,n)

(0,n) se
(1,1) palabra clave obtiene
asocia a
(1, n)
provisión
(0,n) (1,1)

Visitante en (0,n) (1, n)

busca Producto
línea

tiene (t, e) servicio

productos
(0, 1) (1,1) ingresados a
Cliente (1, 1)
(0,n) Cd Libro Video
inclusión
(1, n)

Cliente pertenen- (0, n) (0, n)

Cesta contenido
Registrado cia
(0, n)
(t, e)
consigna-
solicitud Pedido
(0, n) (0, n) ción
(1, n)
Cliente Cliente (1, 1)
Eventual Permanente clasifica-
(1,n) ción
Pedido Flete
(0,n) Criterio de realizado
utiliza búsqueda por (1, n)
categorías

(t,e) Categoría

Flete Expreso
(1,n) (1, n)
Busqueda no Busqueda (0,n) se
exitosa exitosa relaciona

pregunta
(0,n) (0,n)

Figura 4.10 – Diagrama Entidad Relacionamiento Integrado

 44

5. Desarrollo de un Datawarehouse
Dado que el objetivo de la investigación es mejorar las relaciones en base a
los datos registrados, se propone elaborar un datawarehouse que contenga datos de
la base de datos operacional y datos registrados de las interacciones con los usua-
rios. Este datawarehouse debiera elaborarse a partir del Diagrama Entidad Relacio-
namiento Integrado, presentado en la figura 4.10.

Bill Inmon, citado por [Jaar&Prieto98] define datawarehouse como sigue: “Un
datawarehouse organiza y almacena los datos requeridos para el procesamiento
analítico de la información a largo plazo. Es una colección de datos de tipo orientada
a sujetos, integrada, variable en el tiempo y no volátil, para apoyar el proceso de to-
ma de decisiones de gestión“.

Respecto de esta definición [Jaar&Prieto98] detallan que, al decir “los sujetos”

se incluye al cliente, vendedor, producto y actividades. Al datawarehouse le concier-
nen el modelamiento de los datos, el diseño de la base de datos, pero no el de los
procesos que corresponde a una base de datos de tipo operacional. La Integración
se refiere a que los datos que vengan de diferentes bases de datos deben integrarse
y ser consistentes. Por otra parte, los datos del datawarehouse no son actualizados
por transacciones sino cada vez que se le transfieran datos desde las bases de datos
operacionales, por lo tanto, serán precisos para un momento y pueden no serlo para
otro. Finalmente, debe ser fácil de manejar e incluir mecanismos de seguridad.

Para diseñar un datawarehouse se deben realizar dos tareas. Primero debe

desarrollarse un diseño lógico y a continuación se realiza un diseño físico.

Como el formato de los datos no es relevante para el análisis, los datos de las
tablas normalizadas de la base de datos operacional, se deben desnormalizar y en
ocasiones, cambiar el formato. Se trata de armar una base de datos informacional a
partir de la base de datos operacional.

Además, se deben eliminar las inconsistencias y redundancias que pueden

derivarse de la integración de las bases de datos operacionales de distintas áreas de
la organización y filtrar los datos muy específicos que no aportarán en las decisiones
que el datawarehouse apoyará.

5.1 Diseño lógico de la base de datos

Para realizar la primera tarea, es decir, elaborar el diseño lógico de la base de

datos, a partir del DER Integrado, se utilizan las reglas que se proponen en [Heu-
ser01], éstas se resumen en la tabla 5.1.
 45

Para realizar el diseño lógico de las jerarquías de tipo, [Heuser01] propone 2

alternativas. La primera es elaborar una tabla para toda la jerarquía y la segunda es
elaborar una tabla para cada entidad de la jerarquía, ambas alternativas tienen ven-
tajas y desventajas. En este caso se opta por la primera opción, ya que se desea
elaborar datawarehouse para todo el diagrama, por lo tanto, esta opción ahorra
trabajo para la siguiente etapa, que es la integración y desnormalización de todas las
tablas.

Regla de implementación
Tipo de
Relacio- Tabla Adición Fusión
namiento Propia Columna Tablas
Relacionamiento 1:1
(0,1) (0,1) ± ü û
(0,1) (1,1) û ± ü
(1,1) (1,1) û û ü
Relacionamiento 1:n
(0,1) (0,n) ± ü û
(0,1) (1,n) ± ü û
(1,1) (0,n) û ü û
(1,1) (1,n) û ü û
Relacionamientos n:n
(0,n) (0,n) ü û û
(0,n) (1,n) ü û û
(1,n) (1,n) ü û û
ü Alternativa preferida
± Puede ser usada
û No usar
Tabla 5.1 – Reglas para la implementación de relacionamientos [Heuser01]

El resultado del diseño lógico se presenta a continuación, utilizando la misma

notación del diccionario de datos. Esta notación es presentada en la tabla 5.2.
 46

Símbolo Significado
= Está compuesto de
+ Y (conjunción)
( ) Optativo
{ } Iteración o repetición
[ ] Selección de alternativas
| Separador de alternativas
@ Identificador
* * Comentario
Tabla 5.2 – Simbología utilizada en un diccionario de datos

A continuación se presenta el diseño lógico de Diagrama Entidad Relaciona-

miento Integrado.

• Actor = @id actor + actor

• Artista = @id artista + artista

• Asociados a = @id resultado + @id consulta producto

• Autor = @id autor + autor

• Busca = (Nº de búsqueda en la sesión) + @id visitante +@id palabra clave

• Cantidad en estado = @id cantidad en estado + cantidad

• Categoría = @código categoría + nombre categoría

• Cesta = @id cesta + estado cesta + ( nombre cesta ) +@id cliente +@id visi-
tante

• Clasificación = @código categoría + @código producto

• Comentario = @id comentario + comentario

• Consulta = @id visitante + @id consulta producto + (Nº de búsqueda en la

sesión)

• Consulta producto = @id consulta producto + @código producto

• Contenido = @id cesta + @código producto + cantidad

• Criterio de búsqueda por categorías = @id criterio

 47

• Dirección de Despacho = @id dirección de despacho + dirección

• Dirección de regalo = @id dirección de regalo + dirección

• Director = @id director + director

• Editor = @id editor + editor

• Empresa = @RUT + razón social + dirección + @id fono + @id fax + repre-
sentante

• Estado producto = @id estado producto + estado producto

• Evaluación = @id evaluación + evaluación

• Extracto = @id extracto + extracto

• Fax= @id fax + número de teléfono

• Flete = @id flete + tipo flete + cargo fijo + cargo variable +@RUT

• Fono = @id fono + número de teléfono

• Idioma = @id idioma + idioma

• Inclusión = @código producto + @número pedido + @id estado producto +

@id cantidad en estado + cantidad producto

• Narrador = @id narrador + narrador

• Obtiene = @id palabra clave + @id resultado

• Palabra clave = @id palabra clave

• Pedido = @número pedido + fecha pedido + tipo despacho + estado pedido +

autorización pago + fecha cierre+@id cliente + (Fecha consulta)

• Pregunta = @id visitante + @número pedido

• Producto = @código producto + título + @id idioma + observaciones + dispo-

nibilidad + stock + foto + descuento + precio + año publicación + lugar publica-
ción + @id rol + @id comentario + (@id evaluación ) + posición de venta + po-
sición de preferencia + cantidad vendida + promedio evaluaciones + @RUT +
(@id artista + sello + catálogo + pista + ( duración ) + ( duración total ) + for-
 48

mato digital + número de unidades + @id extracto) + (@id autor + @id editor +
editorial + índice contenidos + ISBN + ( edición ) + ( reimpresión ) + ( formato
encuadernación ) + ( número páginas ) + número volúmenes + @id trozo) +
(@id director + @id productor + duración + @id actor + @id narrador + subtitu-
los + sistema + número serie + número de unidades + reseña contenidos +
@id sinopsis)

• Productor = @id productor + productor

• Resultado de la búsqueda = @id resultado + resultado

• Rol = @id rol + rol

• Se relaciona = @id criterio + @código categoría

• Sinopsis = @id sinopsis + sinopsis

• Trozo = @id trozo + trozo

• Utiliza = @id visitante + @id criterio + (Nº de búsqueda en la sesión)

• Visitante en línea = @id visitante + fecha Sesión + hora Sesión + @id co-
nexión + servidor + país + idioma local + hora local+fecha+hora inicio+hora
cierre+ (@id cliente) + (nombre cliente + ( correo electrónico ) + dirección per-
sonal + forma de pago + código cliente + contraseña) +( [ @id dirección de
despacho | @id dirección de regalo ] )

5.2 Integración

Dada la naturaleza de este trabajo, no debe desarrollarse un datawarehouse

del modo tradicional, ya que lo usual sería elaborar una gran base de datos a partir
de varias bases de datos operacionales, y en esta investigación, lo que se quiere es
elaborar una gran base de datos a partir de un DER.

Por lo tanto, se realizan algunos pasos hacia atrás, los datos de las tablas
normalizadas, del diseño lógico, se deben desnormalizar. Además, se eliminan posi-
bles redundancias y se filtran los datos muy específicos que no aportan en las deci-
siones que el datawarehouse apoyará.

De esta forma, se fusionan, entre otras, los campos: fono, fax y empresa; es-
tado producto, cantidad en estado e inclusión; y dir desp, dir regalo y visitante en lí-
nea.
 49

• Producto = @código producto + título + @id idioma + observaciones + dispo-

nibilidad + stock + foto + descuento + pre-cio + año publicación + lugar publi-
cación + rol + comentario + ( evaluación ) + posición de venta + posición de
preferencia + cantidad vendida + promedio evaluaciones + @RUT + ( artista +
sello + catálogo + pista + ( duración ) + ( duración total ) + formato digital +
número de unidades + extracto) + ( autor + editor + editorial + índice conteni-
dos + ISBN + ( edición ) + ( reimpresión ) + ( formato encuadernación ) + (
número páginas ) + número volúmenes + trozo) + ( director + productor + du-
ración + actor + narrador + subtitulos + sistema + número serie + número de
unidades + reseña contenidos + sinopsis)

• Empresa = @RUT + razón social + dirección + fono + fax + representante

• Inclusión = @código producto + @número pedido + estado producto + canti-

dad en estado + cantidad producto

• Visitante en línea = @id visitante + fecha Sesión + hora Sesión + @id co-
nexión + servidor + país + idioma local + hora local+fecha+hora inicio+hora
cierre+ (@id cliente) + (nombre cliente + ( correo electrónico ) + dirección per-
sonal + forma de pago + código cliente + contraseña) +( [ dirección de despa-
cho | dirección de regalo ] )

Con esta y otras reglas propuestas en [Winsberg9?], tales como: Filtrar datos
operacionales irrelevantes, introducir datos derivados, resumir, convertir columnas en
filas, se obtiene el modelo lógico presentado a contunuación:

• Datawarehouse = @código producto + @id conexión + @id flete + @id visi-

tante + @número pedido + @RUT + (@id cliente) + @id cesta + año publica-
ción + autorización pago + cantidad + cantidad producto + cantidad vendida +
cargo fijo + cargo variable + comentario + descuento + dirección + disponibili-
dad + estado cesta + estado pedido + estado producto + evaluación + fax +
fecha + fecha pedido + fecha cierre+ fecha sesión + fono + foto + hora cierre +
hora inicio + hora local + hora Sesión + idioma + idioma local + lugar publica-
ción + nombre categoría + observaciones + país + posición de preferencia +
posición de venta + precio + promedio evaluaciones + razón social + represen-
tante + resultado + rol + servidor + stock + tipo despacho + tipo flete + título +
(artista + sello + catálogo + pista + (duración) + (duración total) + formato digi-
tal + número de unidades + extracto) + (autor + editor + editorial + índice con-
tenidos + ISBN + (edición) + (reimpresión) + (formato encuadernación) + (nú-
mero páginas) + número volúmenes + trozo) + ([dirección de despacho | direc-
ción de regalo] ) + (director + productor + duración + actor + narrador + subti-
tulos + sistema + número serie + número de unidades + reseña contenidos +
sinopsis) + (evaluación) + (Fecha consulta) + (Nº de búsqueda en la sesión) +
 50

(nombre cesta) + (nombre cliente + (correo electrónico) + dirección personal +

forma de pago + código cliente + contraseña)

Posteriormente, este conjunto de campos debería poblarse con datos opera-

cionales y datos que se registren de las navegaciones y consultas realizadas por los
visitantes.

En el capítulo siguiente se proponen algunas aplicaciones que obtienen infor-

mación a partir de los datos registrados.
 51

6. Datamining

Para elaborar este capítulo, se realizó un extenso análisis bibliográfico de artí-

culos que tratan el tema específico de utilizar datamining en la web, encontrando que
incluso ya existe una denominación específica para este tipo de análisis: Web Mi-
ning, por lo que a continuación se resume brevemente en qué consiste.

6.1 Web Mining

Web Mining es un área de investigación muy reciente que combina dos de las
áreas de la investigación: Data Mining y World Wide Web. Aunque aún no existe un
completo consenso sobre lo que es Web Mining, la mayoría de los estudios, tales
como [Wang00] y [Cooley00] diferencia entre tres áreas: Web Mining de contenido,
Web Mining de estructura, y Web Mining de uso.

El Web Mining de contenido se enfoca en el descubrimiento y recuperación de

información útil de la Web, en cuanto a contenido, datos y documentos. Por su parte,
Web mining de estructura enfatiza en el descubrimiento de cómo modelar las estruc-
turas de vínculos de la Web. La distinción entre estas dos categorías no es muy clara
a veces.

Por su parte, Web mining de uso es una categoría relativamente independien-

te de las anteriores, pero no aislada. Esta categoría describe, principalmente, las
técnicas que descubren patrones de uso de los usuarios de sitios web e intenta pre-
decir sus conductas. El Web Mining de uso consta de tres fases, que son: Pre-
procesamiento, Descubrimiento de patrones y Análisis de patrones.

A continuación se explica brevemente cada una de las áreas del Web Mining
mencionadas.

6.1.1 Web Mining de contenido

El Web Mining de contenido describe la búsqueda automática de recursos de

información disponibles online, e involucra grandes volúmenes de datos.

En el dominio del Web Mining, el Web Mining de contenido es esencialmente

análogo a las técnicas de datamining en bases de datos relacionales. El documento
de web normalmente contiene varios tipos de datos, tales como texto, imagen, audio,
video, metadatos e hyperlinks. Algunos de ellos son semi-estructurados como do-
cumentos de HTML, o datos más estructurados como los datos en las tablas o bases
de datos generadas con HTML, pero la mayoría de los datos es texto no estructura-
 52

do. La característica no estructurada de datos obliga a buscar enfoques más compli-

cados.

6.1.2 Web Mining de estructura

La mayoría de las herramientas para recuperar información en la web sólo usa

la información textual, mientras que se ignora la información del vínculo que podría
ser muy valiosa. El objetivo del Web Mining de estructura es generar un resumen
estructural sobre el sitio y sus páginas. Técnicamente, Web Mining de contenido se
enfoca principalmente en la estructura dentro del documento, mientras Web Mining
de estructura intenta descubrir la estructura de vínculos e hyperlinks entre los docu-
mentos. Basado en la arquitectura de hyperlinks, Web Mining de estructura categori-
zará las páginas webs y generará información, tal como la similitud y las relaciones
entre los diferentes sitios web.

6.1.3 Web Mining de uso

Web Mining de uso intenta descubrir la información útil de los datos secunda-
rios derivados de las interacciones de los usuarios mientras navegan en la web. Se
enfoca en las técnicas que podrían predecir el comportamiento del usuario mientras
interactúa con el sitio web.

[Spiliopoulou99] resume los objetivos estratégicos potenciales del Web Mining

de uso como:

• Predicción de la conducta del usuario dentro del sitio,

• Comparación entre las expectativas y el uso real del sitio,
• Ajuste del sitio a los intereses de sus usuarios.

No hay distinciones tan claras entre Web Mining de uso y las otras dos catego-
rías. En el proceso de preparación de los datos de Web Mining de uso, el contenido
del web y la arquitectura del sitio web serán utilizados como fuentes de información,
por lo cual interactúan el Web Mining de uso, Web Mining de contenido y Web Mining
de estructura. Más aún, el clustering en el proceso del descubrimiento de patrones es
un puente desde el Web Mining de contenido y de estructura hacia el Web Mining de
uso.

6.2 Web Mining de uso

Tal como lo define [Cooley00], Web Mining de uso es la aplicación de técnicas

de datamining para descubrir patrones de los datos de la web con el propósito de
entender y mejorar el servicio a las necesidades de aplicaciones basadas en web.
 53

También [Cooley00], propone que el Web Mining de uso sea analizado en tres
fases distintivas, que son: pre-procesamiento, descubrimiento de patrones y análisis
de patrones.

Tal como se muestra en la figura 6.1, la fase de pre-procesamiento del Web

Mining de uso se puede asociar al trabajo expuesto en los capítulos anteriores, don-
de se establece un modelo para registrar los datos de los visitantes en forma orde-
nada y estructurada. A continuación, en la etapa de descubrimiento de patrones, se
utilizaría el datamining. Finalmente, en la etapa de análisis de patrones se deben
tomar las salidas de las etapas anteriores y tomar las decisiones para mejorar las
relaciones con los clientes.

Web Mining de Uso

Descubrimiento Análisis de
Pre-procesamiento
de Patrones Patrones

Integración del DER

operacional y DER Datamining Decisión
navegacional en un
datawarehouse

Figura 6.1 – Web Mining de Uso

A continuación se explica cada una de estas fases.

6.2.1 Datos de Pre-procesamiento para Mining

Del punto de vista de la técnica, Web Mining de uso es la aplicación de técni-

cas de datamining a los logs (datos de Web secundarios) de grandes repositorios de
datos Web. El propósito es producir salidas que puedan usarse en las tareas de di-
seño, tales como: diseño del sitio Web, diseño del servidor de Web y diseño de la
navegabilidad de un sitio de Web [Cooley99].
 54

El Pre-procesamiento de contenido es el proceso de convertir texto, imagen,

escrituras y otros archivos en las formas que pueden ser usadas por el datamining de
uso.

Para determinar los pre-procesamiento de estructura, se debe considerar que

la estructura de un sitio de Web es formada por hyperlinks entre vistas de páginas.
De esta forma, los pre-procesamientos de la estructura pueden tratarse en forma si-
milar como el pre-procesamiento de contenido.

Las entradas de la fase del pre-procesamiento pueden incluir logs del servidor
de web, logs de destinatarios, archivos de registro, index sever logs, y opcionalmente
las estadísticas de análisis anteriores.

Las salidas son el archivo de sesión del usuario, archivo de la transacción, ar-
quitectura del sitio, y clasificaciones de la página.

Por su parte, según [Cooley00], el pre-procesamiento del uso es, probable-

mente, la tarea más difícil en el Web Mining de uso debido a la falta de datos dispo-
nibles.

De aquí que la propuesta de esta investigación, en el sentido de desarrollar un

DER Navegacional e integrarlo con el DER operacional, para registrar datos, es de
mucho valor.

6.2.2 Descubrimiento de patrones

Este es el componente más importante de Web Mining. En el descubrimiento

de los modelos y patrones convergen los algoritmos y técnicas de varias áreas de
investigación, como datamining, machine learning, estadística, y reconocimiento de
patrones. De acuerdo a las técnicas utilizadas en estas áreas, [Wang00] clasifica las
principales como:

1. Análisis estadístico
2. Reglas de asociación
3. Clustering
4. Clasificación
5. Patrón secuencial
6. Modelamiento dependiente

A continuación se explica brevemente cada una de ellas:

 55

6.2.2.1 Análisis Estadístico

Las técnicas estadísticas son las herramientas más poderosas al momento de

extraer conocimiento acerca de los visitantes de un sitio web. Los analistas pueden
realizar diferentes tipos de análisis estadísticos descriptivos basados en diferentes
variables. Analizando la información estadística se puede mejorar la actuación del
sistema y puede reforzar su seguridad, facilitando la tarea de modificación del sitio, y
apoyando las decisiones de marketing.

6.2.2.2 Reglas de Asociación

En el dominio de la web, las páginas, que son a menudo referenciadas juntas,

pueden asociarse. Para esto, pueden usarse técnicas para descubrir correlación en-
tre los elementos de una base de datos de transacciones desordenadas. En [Coo-
ley00] se enfatiza que en el Web Mining de uso, las reglas de asociación se refieren
a los sets de páginas que se acceden juntas. Los diseñadores de Web pueden rees-
tructurar sus sitios eficazmente con el conocimiento de la presencia o ausencia de
reglas de asociación entre sus páginas. Otro empleo de esta información, es que
cuando se requiera cargar una página de un sitio remoto, pueden usarse reglas de
asociación como un trigger para preparar documentos que un usuario tipo solicitará y
así reducir su tiempo de respuesta cuando lo solicite.

6.2.2.3 Clustering

El análisis de clustering es una técnica para agrupar usuarios o artículos de

los datos (páginas) con características similares. Se puede clusterizar información
del usuario o de páginas para facilitar el desarrollo y ejecución de futuras estrategias
de marketing [Cooley99]; como también se pueden clusterizar los usuarios para ayu-
dar a descubrir el grupo de usuarios que tienen un patrón de navegación o compor-
tamiento similar. Esta técnica es muy útil para inferir las características demográficas
de los usuarios y realizar segmentación del mercado en aplicaciones del E-
commerce o proporcionar contenido de web personalizado a los usuarios individua-
les. Además, se puede hacer un clustering de páginas, lo que sería muy útil para
apoyar motores de búsqueda en Internet, cuando se clusterizan grupos de páginas
que tienen contenidos relacionados.

6.2.2.4 Clasificación

La clasificación es la técnica para rutear un artículo en alguna de varias clases

predefinidas. En el dominio web, el webmaster podría usar esta técnica si quiere es-
tablecer un perfil de los usuarios que pertenecen a una clase particular o categoría.
Esto requiere extraer y seleccionar los rasgos que mejor describen las propiedades
 56

de una clase o categoría. La clasificación puede realizarse usando algoritmos de

aprendizaje dirigidos inductivos, tales como Árboles de Decisión, Análisis Bayesiano
de Decisiones, Clasificador del vecino más cercano, Support Vector Machines, etc.
[Cooley00].

6.2.2.5 Patrón secuencial

Esta técnica intenta encontrar el patrón dentro de la sesión, tal que el conjunto
de los itemes sigan la secuencia de otros, en un conjunto de sesiones o episodios
ordenados en el tiempo. Es muy significativo para que el Web marketer pueda pre-
decir la tendencia futura, lo cual ayuda a colocar consejos específicos que apuntan a
ciertos grupos del usuario. Los patrones secuenciales también incluyen algunos otros
tipos de análisis temporales, tales como análisis de tendencia, detección de punto de
cambio, o análisis de similitud [Cooley00].

6.2.2.6 Modelamiento dependiente

El objetivo de esta técnica es establecer un modelo que sea capaz de repre-

sentar dependencias significativas entre las distintas variables del dominio de la web.
La técnica de modelamiento dependiente provee un marco teórico para analizar el
comportamiento de los usuarios, y es potencialmente útil para predecir los consumos
de recursos futuros en la web.

6.2.3 Análisis de patrones

Finalmente, el Análisis de patrones es la fase final de la Web Mining de uso. El

objetivo de este proceso es eliminar las reglas o patrones irrelevantes y extraer las
reglas o patrones interesantes de las salidas del proceso de descubrimiento de pa-
trones.

Las salidas de los algoritmos de Web Mining a menudo, no son adaptables di-
rectamente al entendimiento humano, y por ello se plantea la necesidad de transfor-
marlo en un formato que pueda ser fácilmente asimilable. Esto puede ser hecho con
la ayuda de algunas herramientas y metodologías de análisis. Los dos enfoques más
comunes para el análisis de patrones son: el uso de mecanismos de estructurados
de consultas como SQL, o construir datos multi-dimensionales cúbicos antes de eje-
cutar las operaciones OLAP [Zaiane98]. Se debe destacar que estos métodos asu-
men que la salida de la fase anterior ha sido suficientemente estructurada.
 57

6.3 Desarrollo de un Datamining

Finalmente, se proponen algunas aplicaciones de datamining que, basándose

en el datawarehouse modelado y en la clasificación de Web Mining de uso, según lo
expuesto en la sección anterior, mejoren las relaciones con los visitantes bajo la filo-
sofía CRM.

Las propuestas entregadas no pretenden cubrir todo el espectro de análisis

que podría hacerse con los datos registrados. Sólo se pretende mostrar ciertas apli-
caciones simples que podrían ser de ayuda en la toma de decisiones, ya que la can-
tidad de análisis e información que se puede obtener es inmensurable.

Las aplicaciones se proponen según la clasificación sugerida por [Wang00],

que clasifica las principales como:

6.3.1 Análisis estadístico

• Calcular el porcentaje de visitantes que:

o Compran productos que se entregan en los resultados de la búsqueda

que ellos realizaron.

o Compran productos realizando búsqueda por categoría.

o Compran productos realizando búsqueda por productos.

o Sólo consultan productos y no compran.

o Consultan sus cestas anteriores para comprar.

o Compran libros en idiomas distintos al del lugar en que reside.

o Compran libros con tapas duras y tapas blandas.

o Compran a distintas horas.

o Compran productos en ciertos rangos de precios.

o Compran productos relacionados.

 58

6.3.2 Reglas de asociación

• Detectar los visitantes que:

o Compran libros en idiomas distintos al del lugar en que reside.

o Compran libros con tapas duras y tapas blandas.

o Compran productos relacionados.

o Sólo compran productos en oferta.

6.3.3 Clasificación

• Analizar el perfil de los visitantes:

o Según el tipo de productos que compra.

o Según las categorías en que se encuentran los productos que compran.

o Que sólo compran ofertas.

6.3.4 Patrón secuencial

• Analizar:

o El perfil de los visitantes según los tipos de productos que compra.

o Si existe relación entre el perfil de los visitantes y la empresa de trans-

porte que escogen.

o Si existe relación entre el producto comprado y la empresa de transpor-

te escogida.

6.3.5 Modelamiento dependiente

• Clasificar:

o Los productos de acuerdo al volumen de venta.

 59

o Las empresas de transporte disponibles de acuerdo al número de solici-

tudes de cada uno.

o Las empresas de transporte disponibles de acuerdo al número de que-

jas para cada uno.

Como se ha mencionado anteriormente, estas propuestas de análisis son sólo

algunas de las que se podrían obtener de esta gran cantidad de datos registrados.
Se supone que los distintos usuarios internos deben solicitar qué información requie-
ren del sistema.
 60

7. Aplicación del Datamining al Datawarehouse

Tal como se mencionó en el capítulo 2, el análisis de CRM busca, entre otros
aspectos: segmentar, buscar clientes más rentables, estimar la probabilidad de que
un cliente sea fiel, identificar características comunes a un grupo de clientes y anali-
zar la respuesta de los clientes a determinadas campañas.

Por otra parte, en el capítulo anterior, se mencionaron algunas técnicas para

realizar análisis de datos, clasificándolas en: análisis estadístico, reglas de asocia-
ción, clustering, clasificación, patrón secuencial y modelamiento dependiente.

A continuación se expone un ejemplo de aplicación. Para esto se generó una

serie de datos ficticios -que son presentados en el Anexo 3- basándose en el dawa-
rehouse desarrollado en el capítulo 5, con las definiciones de datamining presenta-
das en el capítulo 6 y con el objetivo de realizar análisis que apoyen el proceso de
CRM, tal como se describió en el capítulo 2.

7.1 Segmentación

Este análisis busca dividir los clientes en pequeños grupos, para que poste-
riormente puedan realizar campañas y enviar anuncios específicos para cada grupo,
dependiendo de sus características.

El criterio que se utiliza para segmentar es el tipo de producto que el cliente

compre, estableciendo también grupos de clientes que compren varios productos.

La forma de calcular este indicador será:

1. Determinar el número de clientes;

2. para cada uno de ellos, calcular cuántos productos de cada tipo ha comprado;
3. eliminar del análisis a los clientes que sólo han comprado una vez;
4. separar los clientes que sólo compran un tipo de producto;
5. separar los clientes que han comprado dos tipos de productos;
6. listar los clientes que compran productos de un tipo, de dos tipos y de los tres
tipos.

Basándose en los datos ficticios propuestos en el Anexo 3, el resultado de es-

ta clasificación es mostrado en la tabla 7.1 y en el gráfico de la figura 7.1.
 61

Sólo CD's Sólo Libros Sólo Videos Libros y CD's CD's y Videos Libros y Videos Los tres
0,3 0,2 0 0,4 0 0 0,1
Tabla 7.1 – Resultado de la Segmentación por tipo de productos comprados.

Segmentación de acuerdo al tipo de producto que los

clientes compren

Sólo CD's
Sólo Libros
Libros y CD's
Los tres
Figura 7.1 – Gráfico de Segmentación

7.2 Búsqueda de los clientes más rentables

Mediante este análisis se busca a los clientes más rentables, ya que para este
ejemplo no se tiene conocimiento de los costos involucrados, esta medición se reali-
za basándose en los ingresos obtenidos por cliente.

La forma de calcular este indicador será:

1. Determinar el número de clientes;

2. para cada uno de ellos, calcular cuántos productos de cada tipo ha comprado
y el valor pagado por cada uno de ellos;
3. calcular cuánto ha pagado cada uno;
4. listar los clientes y el valor pagado en orden descendente.

Basándose en los datos propuestos en el Anexo 3, el resultado de esta clasifi-

cación es presentado en la tabla 7.2 y en el gráfico de la figura 7.2.
 62

Id Cliente Ingresos ($)

3 73000
1 70000
4 59500
7 59500
8 52500
5 38000
9 36500
16 22500
17 22500
6 22000
18 21500
12 20000
15 20000
14 15500
19 15500
20 12000
2 10000
10 10000
11 8500
13 6000
Tabla 7.2 – Clientes que generan más ingresos.

Clientes que generan más ingresos

80000

70000

60000

50000

$ 40000

30000

20000

10000

0
3 1 4 7 8 5 9 16 17 6 18 12 15 14 19 20 2 10 11 13

Clientes

Figura 7.2 – Clientes que generan más ingresos.

 63

7.3 Estimación de la fidelidad de un cliente

Mediante este análisis se busca a los clientes más fieles. Esta estimación se
realiza basándose en la frecuencia de compra por cliente.

La forma de calcular este indicador será:

1. Determinar el número de clientes;

2. para cada uno de ellos, calcular la frecuencia de compra promedio. Para ello
se determina el número pedidos realizados de un cliente y se divide por el
número de días transcurridos entre el primer y el último pedido;
3. listar los clientes y su frecuencia de compra en orden descendente.

Basándose en los datos propuestos en el Anexo 3, el resultado de esta esti-

mación es mostrado en la tabla 7.3 y en el gráfico de la figura 7.3.

Id Cliente 4 6 16 17 7 1 9 8 3 18 5
Indicador 0,285 0,111 0,055 0,045 0,026 0,024 0,021 0,021 0,014 0,006 0,001
Tabla 7.3 – Clientes más fieles.

Clientes más fieles

0,3

0,25

0,2
Indicador

0,15

0,1

0,05

0
4 6 16 17 7 1 9 8 3 18 5

Clientes

Figura 7.3 – Clientes más fieles.

 64

8. Conclusiones
El gran auge de Internet y el crecimiento explosivo de las transacciones vía
web motiva a que un gran número de empresas realicen ventas en línea a través de
la red y aprovechando las particularidades de Internet, adopten una filosofía orienta-
da al cliente, a través de CRM.

Sin embargo, cuantiosos sitios de comercio electrónico se desarrollan sin una

adecuada planificación y modelamiento, lo que se traduce en que no se utilicen todas
las potencialidades que entrega Internet o las nuevas tecnologías de información.

Se vuelve a confirmar entonces la necesidad de enfatizar que se debe mode-

lar conceptualmente un sistema antes de implementarlo.

Esta Tesis entrega el resultado de la investigación respecto a modelar la rela-

ción o interacción de los clientes o visitantes con un sitio web de comercio electróni-
co. La motivación de obtener un modelo es que éste sirva para registrar las interac-
ciones de los visitantes sin tener que consultarles ni molestarles. Se podría decir que
sirve para seguir los pasos de los visitantes en el sitio, para conocerlos de mejor for-
ma y poder atenderlos de acuerdo a los gustos, requerimientos y particularidades de
cada uno.

Se utiliza un esquema navegacional que representa las interacciones de los

visitantes del sitio web a través de una metodología propuesta en [Schwa-
be&Vilain99]. Este modelo, se ha desarrollado pensando en integrarlo a modelos
orientados a objeto, mas bajo algunos supuestos puede relacionarse con el DER, por
lo que se vislumbra que en el futuro será de apoyo en muchos estudios que involu-
cren modelamiento de usuarios en Internet e intranets, independientemente del pa-
radigma que se utilice.

Un aporte específico de la investigación es la integración que se realiza entre

el DER que registra interacciones del sitio con el DER operacional del negocio. En
este punto se debe aclarar que esta integración y el modelo final serían muy difíciles
de obtener si no existe un DER operacional, ya que en ese caso se debiera comen-
zar por modelar conceptualmente la base de datos operacional. Por su parte, si el
negocio cuenta con un Diagrama de Clases operacional, podría obtenerse el modelo
final de manera similar a la expuesta en esta Tesis, considerando algunas diferencias
entre estos diagramas.

Se debe hacer notar también, que la integración entre estos diagramas se rea-
liza de forma natural y sin recurrir a otros mecanismos más que los existentes en el
modelamiento conceptual del Diagrama Entidad Relacionamiento. En general, se
producen relaciones de subconjunto entre algunas entidades del DER operacional y
del DER navegacional, por lo que se deben crear algunas jerarquías de tipos, las que
 65

en definitiva integrararán los dos diagramas obteniendo el Diagrama Entidad Rela-

cionamiento Integrado.

Con el propósito de apreciar la facilidad que tiene llevar a la práctica esta in-
vestigación, se elabora el diseño lógico de la base de datos del DER Integrado utili-
zando las reglas [Heuser01] y un datawarehouse a partir de ella. Se opta por diseñar
un datawarehouse tabular, en desmedro de uno multidimensional, sólo por motivos
didácticos, lo que no necesariamente implica que este diseño sea siempre el mejor.

Además, se investiga un área nueva dentro del datamining como lo es Web

Mining, enfocándose principalmente en el Web Mining de uso. Esta área o disciplina
formaliza la necesidad de obtener información de la web, y propone metodologías
para hacerlo. Sin embargo, esta es un área relativamente nueva, por lo que muchas
proposiciones están aún en elaboración.

Web Mining es un área de investigación muy reciente que combina dos de las
áreas de la investigación: Data Mining y World Wide Web. Aunque aún no existe un
completo consenso sobre lo que es Web Mining, la mayoría de los estudios, tales
como [Wang00] y [Cooley00] diferencia entre tres áreas: Web Mining de contenido,
Web Mining de estructura y Web Mining de uso. El Web Mining de contenido se en-
foca en el descubrimiento y recuperación de información útil de la Web, en cuanto a
contenido, datos y documentos. Por su parte, Web mining de estructura enfatiza en
el descubrimiento de modelos de estructura de vínculos de la Web. Web mining de
uso es una categoría relativamente independiente de las anteriores, pero no aislada.
Esta categoría describe, principalmente, las técnicas que descubren patrones de uso
de los usuarios de sitios web e intenta predecir sus conductas. El Web Mining de uso
consta de tres fases, que son: Pre-procesamiento, Descubrimiento de patrones y
Análisis de patrones.

Cabe destacar que el Diagrama Entidad Relacionamiento Integrado es de gran

utilidad en la etapa de Pre-procesamiento del Web Mining de uso. El Pre-
procesamiento es el proceso de convertir texto, imagen, escrituras y otros datos en
formas que puedan ser usadas por el datamining de uso. Las salidas de esta etapa
servirán para ser analizadas en la siguiente etapa de Descubrimiento de Patrones.
Según [Cooley00], el Pre-procesamiento del uso es la tarea más difícil en el Web Mi-
ning de uso. De aquí que la propuesta de esta investigación es de mucho valor al
hacer un Pre-procesamiento más claro y perdurable.

Como parte del objetivo de la investigación fue elaborar un modelo para apo-
yar la toma de decisiones, en el último capítulo se proponen algunas aplicaciones
simples para obtener información, basándose en la filosofía CRM. Aunque esta filo-
sofía sirvió de marco para obtener un tipo de información, no debe ser una restricción
para obtener otra información que pueda apoyar a los tomadores de decisiones y
perfectamente podría obtenerse información bajo otra filosofía.
 66

Se proponen aplicaciones simples, por lo que pudiera parecer que no sacan

provecho del esfuerzo anterior de modelar y registrar los datos en forma ordenada.
No obstante, se espera que, en la práctica, los tomadores de decisiones en conjunto
con los analistas expertos, debieran proponer aplicaciones más complejas que se
pudieran construir a partir de los datos registrados.

Finalmente, se plantea que esta investigación debiera ser de utilidad para futu-
ros trabajos e investigaciones que se realizarán en torno al tema de sistemas en In-
ternet e intranets que, debido a la estandarización y a la explosión de las comunica-
ciones, debieran aumentar cada vez más. Algunas ideas al respecto son:

• A partir del datawarehouse desarrollado, elaborar dataminings más robustos y

complejos, que saquen partido de la gran cantidad de datos que se pueden
registrar.

• Aplicar esta propuesta completa a un sitio de comercio electrónico existente,

para que los analistas, diseñadores y decisores puedan apoyarse.

• Aplicar esta propuesta completa a un sitio web que no sea de comercio elec-
trónico, tal como el sitio web de la Escuela de Ingeniería Industrial de la UCV,
ya que la proposición que se realiza en esta investigación no debería enmar-
carse solamente en comercio electrónico.

• Modelar un sistema de intranet organizacional con OOHDM y registrar las in-

teracciones para posteriormente proponer rediseños funcionales y estructura-
les.

• Analizar un caso similar al utilizado en este trabajo, en que se cuente con un

Diagrama de Clases de la base de datos operacional, de este modo analizar si
las asociaciones entre clases son similares a las asociaciones entre entidades,
y conocer si el desarrollo posterior tiene mayor o menor dificultad.
 67

Anexo 1: Extracto de Notación de la Metodología

OOHDM2

1 Introducción

Este trabajo presenta la notación de la metodología OOHDM (Object-Oriented

Hypermedia Design Method) [Rossi96].

OOHDM propone 4 actividades durante la construcción de una aplicación hi-

permedia: modelamiento conceptual, modelamiento navegacional, proyecto de inter-
faz abstracta e implementación. Las tres primeras actividades son desarrolladas ite-
rativamente, la actividad de implementación se desarrolla a continuación o término
de las primeras.

Este trabajo presenta los conceptos que pueden ser representados y la nota-
ción para representarlos, para cada actividad de OOHDM.

El capítulo 2 presenta las actividades de modelamiento conceptual. El mode-

lamiento conceptual analiza el dominio de la aplicación que será desarrollada, enten-
diendo que solamente parte de este dominio será aplicación. En ese capítulo son
presentados todos los conceptos utilizados en modelamiento conceptual y la nota-
ción para cada concepto. La notación usada en modelamiento conceptual está basa-
da en la notación de UML (Unified Modeling Language) [UML].

El capítulo 3 presenta las actividades de modelamiento navegacional. El mo-

delamiento navegacional mapea el esquema conceptual para la definición de la apli-
cación hipermedia que será desarrollada, definiendo visiones de acuerdo con cada
tipo de usuario. Puede ser dividido en dos sub-actividades: definición del esquema
navegacional y la definición del esquema de contextos navegacionales. En este capí-
tulo son presentados todos los conceptos utilizados en modelamiento navegacional.
Debido a que UML no trata el concepto de contexto navegacional, se desarrolla la
notación del esquema navegacional basándose en UML.

El capítulo 4 presenta las actividades de proyecto de interfase abstracta. El

proyecto de interfase abstracta define los objetos de interfase, sus propiedades y
transformaciones. En ese capítulo son presentados todos los conceptos utilizados en
el proyecto de interfase abstracta y la notación de cada concepto.

2
Traducción realizada por Rodrigo Alfaro de “Notação da Metodologia OOHDM”, Daniel Schwabe
& Patrícia Vilain. Río de Janeiro, Abril de 1999.
 68

Por último, el capítulo 5 presenta las actividades de implementación. La im-

plementación transforma el resultado del proyecto navegacional en el proyecto de
interfase abstracta para un ambiente de implementación. En ese capítulo son presen-
tados algunos conceptos relacionados con la implementación.

La figura A.1 presenta el esquema conceptual (Diagrama de Clases) y la figu-

ra A.2 el esquema navegacional resultante del esquema conceptual. Este esquema
incluye el objeto rector. A pesar de que las posibles navegaciones entre las instan-
cias de clases navegacionales serán representadas por las líneas direccionadas y
también por las anclas (âncoras) e índices como atributos, solamente algunas anclas
e índices están siendo representados.
 69

Laboratorio 1 1..*
Persona Equipamiento
nombre: String * nombre: String nombre: String
título: String *
descripción: String
descripción: [Texto + ,
Imagen] conduce Patrocinador
actúa
nombre: String
*
1..* financia
1..* 1..*
participa
Administrativo Técnico Académico Proyecto de Investigación
1..* *
nombre: String
descripción: [TextoMarketing,
TextoPesquisa]
*
1 actúa
Estudiante * Profesor 1..*
actúa
1..* clase: String Área de Investigación
salario-base: 1..* 1..*
nombre: String
1 1..* descripción: String
Orientación
título: String 1
evaluación: Integer rector

enseña dirige nombre: String

*
1..* Asignatura
1 1..* Material Complementario
nombre: String
descripción: String local: String
número-créditos: Integer
Frecuencia ementa: Texto
evaluación: Integer
* *
pré-requisito

requiere
Figura A1.1 – Esquema Conceptual
 70

Persona Laboratorio
nombre: String * nombre: String
título: String *
descripción: String
descripción: Imagen* profs-ind: índice (actúa)
descripción: Texto proyectos: âncora (índice (conduz)) conduce
email: String
actúa
1..*
1..*
participa Proyecto de Investigación
Administrativo Técnico Académico
1..* * nombre: String
nombrePatrocinador: lista String
profs-ind: indice (participa)
*

orienta 1 actúa
* 1..*
Estudiante Profesor
actúa Área de Investigación
título: String clase: String
evaluación: Real areas-ind: índice (actúa) 1..* 1..* nombre: String
salario-base: Real descripción: String
1 proyectos: âncora (índice
1 1..* (Projeto
frecuenta
1
enseña rector
dirige nombre: String
1..* *
Asignatura Estudiante 1..* 1 Asignatura
1 1..* Material Complemen-
evaluación: Integer nombre: String
nombreDisciplina: String posee descripción: String local: String
nombreEstudiante: String número-créditos: Integer
ementa: Texto
* *
pré-requisito

requer
Figura A1.2 – Esquema Navegacional
 71

2 Esquema de Contextos Navegacionales

A continuación se realiza una definición del esquema de clases navegaciona-

les, es necesario definir en cuáles contextos será permitida la navegación entre las
informaciones y cómo ellas serán presentadas. Como UML no presenta notación pa-
ra contextos de navegación, las notaciones usadas a seguir son propias de OOHDM.

2.1 Contexto Navegacional

Un contexto navegacional es un conjunto de objetos que están relacionados

de acuerdo con algún aspecto (e.g. los de un mismo tipo que presentan un atributo
con o mismo contenido; los de un mismo tipo que presentan un relacionamento con
otro tipo; los de tipos diferentes que presentan una característica en común, etc.). Un
contexto puede tener objetos de una única clase o puede tener objetos de varias cla-
ses. Como ejemplos de contextos navegacionales podemos citar: todos los profeso-
res de un departamento, los profesores de una determinada área de investigación,
las disciplinas enseñadas por un profesor, los profesores de estudiantes que practi-
can un determinado deporte, etc.

Los objetos de un contexto de navegación pueden formar parte de varios con-

textos. Por ejemplo, un profesor puede participar del contexto profesor por Departa-
mento prof

que independiente del contexto al cual un objeto está siendo accesado, él presenta
.

contexto, como será visto adelante.

2.1.1 Representación de los contextos

Un contexto es representado por un rectángulo con un identificador. Los con-

textos en general son colocados dentro de otro rectángulo sombreado, que represen-
ta la clase navegacional de sus elementos, que presenta un identificador en cursiva.

La figura A1.3 presenta los contextos profesor por Nombre, que contienen to-
dos los profesores, y profesor por Grado Igual a Doctor, que contienen solamente los
profesores doctores. Un triángulo representado junto al contexto significa que los
elementos del contexto pueden presentar varios criterios de ordenación. Por ejemplo,
puede ser especificado que los profesores pertenecientes a ese contexto pueden ser
ordenados por orden alfabético o por tiempo de servicio.
 72

Profesor
Menú
Principal
Profesores Alfabético

Profesores Doctores Grado = ‘Doctor’

Figura A1.3 – Representación de un contexto

Generalmente el acceso a los elementos de un contexto es hecho a través de
un índice. Los índices son representados por rectángulos de líneas discontinuas
gruesas. Los índices exclusivos para el acceso a los elementos de una clase en de-
terminado contexto generalmente poseen como identificador el nombre de clase en
plural. Por ejemplo, el índice para acceso a los elementos de clase profesor en el
contexto profesor por nombre es denominado profesores.

Para representar que un índice o elemento de un contexto puede ser accesa-

do a partir de cualquier parte, se utiliza una flecha con un círculo en su extremo,
(Landmark) en la figura A1.3 el índice de todos los profesores puede ser accesado a
partir de cualquier lugar.

La figura A1.4 presenta el contexto profesor por Área Igual a Redes de Compu-
tadores. En este contexto los elementos del conjunto de profesores que trabajan en
área Redes de Computadores son accesados a partir de el profesor pertenece-a Área
de Investigación (con cardinalidad 1-N). El rectángulo pequeño en parte superior iz-
quierda del contexto representa un índice asociado a un contexto, significa que el
acceso a cualquier elemento del contexto sólo puede ser hecho a través de este ín-
dice. Ese rectángulo es utilizado para simplificar la representación de los contextos
cuyos elementos son accesados, a partir de objetos fuera del él, solamente a través
de un índice.

Profesor
Menú
Principal
Profesores de Redes Área = ‘Redes’

Figura A1.4 – ejemplo de un contexto

Los elementos de un contexto de navegación también pueden ser escogidos
arbitrariamente a partir de una o más clases (contexto enumerado). Como ejemplo
 73

de este tipo de contexto podemos citar una ruta guiada a personas pertenecientes al
departamento que son adeptas a deportes extremos. La figura A1.5 muestra el con-
texto Deportistas Extremos que está formado por objetos de clase profesor y por obje-
tos de clase Estudiante. Los elementos accesados a partir de ese contexto son pre-
sentados por cartas de contexto, como será visto adelante.

Profesor +
Menú Estudiante
Principal Praticantes
Deportes Deportistas
Extremos Extremos

Figura A1.5 – Contexto con elementos de varias clases

En ciertas circunstancias, puede ser necesario presentar explícitamente todas
las instancias de clases navegacionales que son accesadas en un contexto. En este
caso, el contexto es representado por un rectángulo con un identificador, que contie-
ne otros rectángulos con bordes redondeados, que representan las instancias de los
objetos navegacionales que forman parte del contexto. Como las instancias son pre-
sentadas en un diagrama de contexto, ellas no requieren ser especificadas en las
cartas de contexto.

La figura A1.6 presenta el contexto Terreno donde son mostradas las instan-
cias de clase Laboratorio que están localizadas en el terreno. La flecha con círculo
representa que los Lab. de Redes pueden ser accesados a partir de cualquier lugar.

Laboratorio
Menú
Principal Laboratorios Terreno
en Terreno
Lab. de Redes

Lab. de
Microelectrónica

Figura A1.6 – Contexto de instancias

Un contexto de navegación también puede ser formado por los elementos re-
sultantes de una consulta realizada en el momento de la navegación. Los parámetros
de consulta pueden ser definidos automáticamente por el sistema o interactivamente
por el usuario. La figura A1.7 presenta un contexto donde la consulta es realizada en
la clase Proyectos de Investigación con un profesor de una área como parámetro, a
 74

partir de las clases profesor de Área. En este ejemplo la consulta para accesar los
proyectos de un profesor en determinada área es realizada a través de un profesor
de una área. El índice de acceso a un contexto por consulta debe presentar una ba-
rra vertical ennegrecida al lado derecho, indicando que la entrada es determinada
durante al navegación (índice dinámico).

Proyecto de
Menú Investigación
Principal
Proyectos por Consulta

Figura A1.7 – Contexto de navegación por consulta

En OOHDM, además del concepto de contexto, existe el concepto de grupo

de contexto, que es un conjunto de contextos. La ventaja de especificar un grupo de
contextos es que esto se realiza a través de una única especificación parametrizada,
tornándose más compacta. Esos grupos de contextos son representados de manera
similar a un contexto simple, o sea, por un rectángulo contenido un identificador. Por
ejemplo, el conjunto de todos los contextos para los profesores de acuerdo con una
grado es representado por un grupo de contexto, profesor por grado. Este grupo de
contexto representa el conjunto de los contextos profesor por grado Igual a Doctora-
do, profesor por grado Igual a Maestría, profesor por grado Igual a Graduación, etc. La
figura A1.8 presenta el grupo de contexto profesor por grado.

Profesor
Menú
Principal
Profesores por Grado
Grados

Figura A1.8 – Grupo de contexto

Un grupo de contextos, en este caso, es obtenido a través de la determinación
de propiedades de los objetos, grado, cuyos posibles valores determinan cada con-
texto simple que forma un grupo. Por lo tanto, un grupo de contextos puede ser de-
terminado a través de propiedades con un parámetro, cada contexto simple de este
grupo será determinado por las propiedades de las instancias, valorizando sus pará-
metros. Del ejemplo anterior, tenemos
 75

profesor por grado : Ct i t = {(P pertenece a profesores, P.grado = tit}}

La figura A1.9 presenta otro ejemplo de grupo de contexto. El grupo de con-

texto profesor por Área representa todos los contextos derivados del (1-N) profesor
pertenece-a Área de Investigación, o sea, representa el conjunto de contextos profesor
por Área Igual a Redes de Computadores, profesor por Área Igual a Ingeniería de Soft-
ware, profesor por Área Igual a Inteligencia Artificial, etc.

Profesor
Menú
Principal
Área Profesores por Área

Figura A1.9 – ejemplo de grupo de contexto

Este es otro ejemplo en el cual un conjunto de contextos simples está formado
a partir de una relación 1-N; para cada valor de origen, se forma el contexto con los
N valores posibles de destino.

El acceso a un contexto puede presentar un parámetro. En este caso el pará-

metro puede indicar un elemento de un contexto, un elemento de un grupo de con-
texto o un contexto de un grupo de contexto. A figura A1.10 presenta tres ejemplos
de parámetros.

Laboratorio
Laboratorio = ‘Lab. de Redes’
Menú Alfabético
Principal Laboratorios

Laboratorio = ‘Redes:Lab. de ES’

por Área de
Investigación
Área = ‘Redes’

Figura A1.10 – Entrada de parámetros para un contexto e grupo de contexto

El parámetro laboratorio = ‘Lab de Redes’ pasado a contexto Laboratorio Alfa-
bético indica que el objeto ‘Lab. de Redes’ será accesado directamente a partir de
 76

Menú Principal. A partir de este laboratorio, los otros laboratorios pertenecientes a

contexto podrían ser accesados.

El parámetro laboratorio = ‘ES:Lab de ES’ pasado a grupo de contexto Labo-

ratorio por Área de Investigación indica que a la instancia ‘Lab. de ES’ en el contexto
Laboratorio por Área = ‘ES’ será accesado directamente a partir de Menú Principal.
A partir de esta instancia, las demás instancias (los otros laboratorios) que pertene-
cen a contexto Laboratorio por Área = ‘ES’ podrían ser accesados.

El parámetro área = ‘Redes’ pasado a grupo de contexto Laboratorio por Área

de Investigación indica que el índice de contexto simple Laboratorio por Área = ‘Re-
des’, indicado por el pequeño rectángulo, puede ser accesado directamente del Menú
Principal.

2.1.2 Contexto dinámico

Un contexto puede ser dinámico o no. Un contexto de navegación dinámico es

aquel cuyos elementos son definidos o alterados durante la navegación. Un contexto
dinámico es representado por un rectángulo con una barra vertical ennegrecida al
lado derecho.

La figura A1.11 muestra el ejemplo de un contexto de navegación dinámico, el

contexto Asignatura por Requisito, donde un conjunto de asignaturas son selecciona-
das por un alumno para su posterior matrícula.

Puede observarse en figura A1.11 que la navegación entre el contexto Asigna-

tura Alfabético y el contexto Asignatura por Requisito está representada por una línea
con doble flecha, significando que está permitido el retorno a la instancia de cual a
navegación fue iniciada.

Asignatura
Menú s
Principal
Asignaturas Alfabético

por Requisito

Figura A1.11 – Contexto de navegación dinámico

Una clase navegacional también puede presentar un contexto de creación,
modificación o eliminación de sus instancias. Por ejemplo, una aplicación puede
permitir, durante su ejecución, la inclusión de un profesor en una determinada área,
 77

en tanto ella presenta el contexto dinámico creación, ver figura A1.12. Todos los otros
contextos especificados por propiedades o relaciones de clase profesor también son
considerados dinámicos; por ejemplo, o contexto profesor por Área Igual a Redes de
Computadores es dinámico.

La creación de una instancia u objeto está representada por un rectángulo con

bordes redondeados y una barra vertical del lado derecho. Cuando una clase posee
un contexto de creación, modificación o eliminación, los otros contextos, a pesar de
ser dinámicos, no precisan presentar una barra vertical ennegrecida al lado derecho.

En muchos casos, es interesante permitir que, cuando un objeto pertenece a

más de un contexto de navegación, sea posible moverse de la navegación para ocu-
rrir dentro de otro contexto al cual el objeto pertenece. La línea trazada separando
los contextos representa que no es posible navegar a partir de un elemento de un
contexto para el otro contexto. Cuando la línea no es presentada, es posible navegar
a partir de un contexto para cualquier otro contexto.

La elipse asociada al contexto creación indica que el acceso a ese contexto

está protegido, o sea, solamente usuarios con permiso podrían accesarla.

Profesor
Menú
Principal
Profesores de Redes Área = ‘Redes’

Inclusión de un Creación
Profesor

Figura A1.12 – Contexto de creación

Cuando las operaciones de creación, modificación o eliminación de objetos in-

fluencian o son influenciadas por los otros objetos del contexto, ellas deben ser es-
pecificadas en cartas de contexto. En caso contrario, una operación es especificada
en cartas de clase navegacional. Por ejemplo, dos asignaturas que presentan el
mismo horario no pueden ser incluidas en una misma matrícula. Por tanto, la opera-
ción de inclusión de una asignatura en una matrícula es especificada es cartas de
contexto de inclusión de una asignatura en matrícula.
 78

2.1.3 Contexto Persistente y no Persistente

Los contextos pueden ser persistentes o no. Un contexto no persistente existe

solamente durante a sesión de navegación donde él fue creado. Un contexto persis-
tente, a continuación de ser creado, puede ser accesado en diversas sesiones de
navegación.

No existe representación explícita para un contexto persistente y en un

contexto no persistente. Con todo, para que un contexto no persistente sea
transformado en un contexto persistente debe estar disponible una operación de
rescate en el contexto, especificada en las cartas respectivas.

2.1.4 Generalización de Contexto

Cuando el esquema navegacional presenta una generalización de clases na-

vegacionales, el esquema de contextos también puede presentar una generalización
de contextos.

La generalización de contextos es utilizada para representar que todas las

subclases de una clase navegacional presentan uno o más contextos en común. Es-
tos contextos son incluidos como contextos de superclase y heredados por todas las
subclases.

La figura A1.13 presenta un ejemplo de generalización de un contexto consi-

derando parte del esquema navegacional presentado en figura A1.2 Las subclases
son incluidas dentro de un rectángulo representante de la superclase, que es repre-
sentado por tonalidades de gris diferente.
 79

Académico

por Laboratorio

Profesor

Profesores Alfabético

por Área de
Investigación

Estudiante

Estudiantes Alfabético
Menú
Principal

Área de Investigación
Áreas de Alfabético
Investigación
por Laboratório

Laboratorio

Laboratorios Alfabético

Figura A1.13 – Generalización de contextos

En este ejemplo, el contexto por Laboratorio fue generalizado porque todas
las subclases de Académico (subclases Profesor y Estudiante) presentan el contexto
por Laboratorio y, además de eso, todas las instancias de Profesor y Estudiante son
accesadas juntas a través del contexto por Laboratorio.

A pesar de las subclases Profesor y Estudiante presentan el contexto Alfabéti-

co, él no fue generalizado porque las instancias de esas subclases son accesadas
separadamente.

2.1.5 Navegación en los Contextos

La navegación dentro de un contexto puede ser realizada de diversas formas:

 80

• Navegacional Secuencial
Los elementos del contexto son accesados en un orden secuencial pre-
establecido. En la navegación secuencial el contexto define los elementos prime-
ro, último, próximo y anterior de cada elemento.

• Navegacional Circular
Los elementos del contexto también son accesados en orden secuencial pre-
establecido, por orden circular. Esta navegación difiere de la navegación secuen-
cial por no presentar el primero y el último elemento.

• Navegacional Libre
Los elementos del contexto no precisan ser accesados en orden secuencial, a
pesar de que eso también puede ocurrir, pues pueden ser definidos los elemen-
tos primero, último, próximo y anterior. En esta navegación un elemento puede
ser accesado a partir de cualquier otro.

• Navegacional Limitada al Índice

Los elementos del contexto son accesados solamente a partir del índice, o sea,
después de accesar un elemento a través del índice, obligatoriamente se retorna
al índice, y a partir de él es accesado el próximo elemento buscado.

• Combinación de Navegacional por Índice y Secuencial

Los elementos del contexto pueden ser accesados tanto por el índice como por
el elemento anterior y el próximo.
 81

2.1.5 Cartas de un Contexto

Para cada contexto o grupo de contexto de navegación es necesario especifi-

car una carta con sus propiedades, ver figura A1.14.

Contexto:
Elementos:
parámetros:
clases en Contexto:
Navegación Interna:
Restricciones de Uso
usuario: permiso:
operaciones:
Comentarios:
Figura A1.14 – Cartas de contexto o grupo de contexto

Los nombres de los campos de cartas de contexto son bastante significativos.

El campo Elementos explicita, de manera más formal, todos los elementos

que forman parte del contexto. Cuando el contexto es enumerado, los elementos de-
ben ser especificados explícitamente.

El campo parámetros presenta los parámetros que son pasados durante a

definición del contexto. El parámetro puede ser una instancia de clase o un valor de
un atributo. Ese campo es utilizado solamente por los grupos de contexto. En una
especificación de un contexto simple, ese campo permanece vacío.

El campo clases en Contexto presenta la lista de las clases en contexto defi-

nidas para el contexto en cuestión. Esa lista incluye una clase en contexto para cada
clase participante del contexto necesario.

El campo Navegación Interna define cual es el tipo de navegación permitida

entre los elementos del contexto (secuencial, circular y/o por índice o una combina-
ción de estas). En caso de un contexto que presenta una navegación secuencial o
circular debe ser especificado el criterio de ordenación de los elementos. Un mismo
contexto puede tener diversos criterios de ordenación (ordenación múltiple), siendo
que todos los criterios deben ser especificados en un criterio default debe ser indica-
do por el caracter “+”. En determinadas aplicaciones, también puede ser necesario
especificar, para algunos contextos que presentan navegación únicamente secuen-
cial y/o circular, los puntos de entrada obligatorios del contexto, o sea, los elementos
por los cuales el contexto siempre será accesado (ej.: primer elemento, último ele-
mento). Todos los contextos que contienen elementos de una clase que es accesada
 82

a través de un vínculo que participa de un papel con las propiedades {ordenado},

deben presentar o mismo criterio de ordenación.

El campo Restricciones de Uso permite indicar los permisos de acceso para

cada clase de usuarios del contexto. Todos los usuarios de un contexto, de una mis-
ma clase, poseen los mismos permisos de acceso.

El campo operaciones presenta las operaciones del contexto, o sea, las ope-
raciones que manipulan los elementos del contexto.

A figura A1.15 especifica la carta de contexto para o contexto profesor por

grado Igual a Doctor, presentado en figura A1.3.

Contexto: profesor por grado Igual a Doctor

Elementos: P: profesor DONDE P.titulación = ‘Doctor’
parámetros:
clases en Contexto:
Navegacional Interna: secuencial, [(ORDENADA POR P.Nombre,
Ascendente)+,(ORDENADA POR P.tiempoServicio, Ascendente)]
Restricciones de Uso
usuario: todos permiso: lectura
operaciones:
Comentarios:
Figura A1.15 – Carta del contexto

La figura A1.16 especifica la carta de contexto para el grupo de contexto pro-

fesor por Área presentado en figura A1.9. Como este contexto presenta la navega-
ción por índice, a partir de un elemento del contexto es necesario retornar a índice
para accesar otro elemento del contexto.

Contexto: profesor por Área

Elementos: P: profesor DONDE P pertenece-a A
parámetros: A: Área de Investigación
clases en Contexto:
Navegacional Interna: por índice
Restricciones de Uso
usuario: permiso:
Operaciones:
 83

Comentarios:
Figura A1.16 – Carta de contexto o grupo de contexto

2.2 Estructuras de acceso

Las estructuras de acceso son índices que permiten o acceso a los contextos.
Un ejemplo de estructura de acceso es el índice de acceso a los profesores ordena-
dos por su nombre, o sea, los elementos del contexto profesor Alfabético.

Las estructuras de acceso son representadas, como se ha dicho anteriormen-

te, por rectángulos con líneas discontinuas gruesas. La figura A1.17 muestra la re-
presentación de estructura de acceso profesores que permite el acceso a todos los
profesores.

Profesores
Figura A1.17 – estructura de acceso profesores
Las estructuras de acceso pueden poseer varios criterios de ordenación, pu-
diendo alternar entre esos criterios. Cuando son definidos varios criterios de ordena-
ción, ellos son especificados entre corchetes y separados por “,”. El criterio default es
indicado por el signo “+” en la carta de estructura de acceso, como será visto adelan-
te. La figura A1.18 muestra la estructura de acceso profesores que presenta múltiples
criterios de ordenación esta es representada adicionando un triángulo invertido en-
negrecido en su lado izquierdo.

Profesores

Figura A1.18 – estructura de acceso con múltiples criterios de ordenación

Las figuras A1.19 e A1.20 muestran ejemplos de estructuras de acceso con

múltiples criterios de ordenación.
 84

Profesor
Menú
Principal
Profesores Alfabético

Figura A1.19 – Índice con un contexto como destino

En la figura A1.19, independiente del criterio de ordenación presentado en la
estructura de acceso, el acceso a los elementos del contexto es realizado siempre de
acuerdo con el criterio de ordenación especificado en el contexto.

Profesor
Menú
Principal
<ord>
Profesores Alfabético

Figura A1.20 – Índice con un contexto como destino

En la figura A1.20, <ord> indica que cuando el contexto Profesor Alfabético es
accesado a través del índice Profesores, él presenta el mismo criterio de ordenación
del índice. En este caso, el contexto debe presentar el criterio de ordenación del índi-
ce. Si el contexto es accesado por otro camino, en tanto sus elementos son presen-
tados de acuerdo con el criterio de ordenación default.

La figura A1.21 presenta una estructura de acceso que puede tener varios
contextos como destino. El contexto accesado depende del atributo accesado en la
estructura de acceso. La especificación de cual contexto será accesado es hecha en
las cartas de estructura de acceso.
 85

Profesor
Menú
Principal Alfabético
Profesores

por Título

Figura A1.21 – Índice con varios contextos como destino

Una estructura de acceso también puede ser jerárquica. Una estructura de ac-
ceso jerárquica representa un conjunto de índices secuenciales, donde la selección
en un nivel determina los elementos del próximo nivel. Es usada para simplificar los
diagramas de contexto. El rótulo de un índice jerárquico es formado por los atributos
que forman la jerarquía, separados por ‘:’. Los atributos usados en los sucesivos refi-
namientos de los índices pueden ser los nombres de las clases o los atributos de la
clase. La figura A1.22 muestra un índice jerárquico representando 2 estructuras de
acceso, donde cada nivel depende de la selección hecha en el nivel anterior.

Profesores : Áreas
Figura A1.22 – estructura de acceso jerárquica
Asimismo como los contextos de navegación, las estructuras de acceso tam-
bién son especificadas a través de cartas. La figura A1.23 presenta la especificación
de la estructura de acceso profesores presentada en figura A1.5.
 86

estructura de acceso: profesores Tipo: simples

parámetros:
Elementos: P: profesor
Atributos: Destino:
P.nombre P: profesor DONDE P pertenece-a profesor Alfa-
bético
P.título
-
ordenación: ORDENADA POR P.nombre, ASCENDENTE
Restricciones de Uso
usuario: todos permiso: lectura
Comentarios:
Depende de: Nav profesor Influencia: ADV profesores
Figura A1.23 – Cartas de estructura de acceso profesores
Donde:

El tipo de estructura de acceso puede ser simple, jerárquico o dinámico.

El campo parámetros especifica los parámetros necesarios para determinar

los elementos del índice.

El campo Elementos especifica los elementos que serán mostrados en el ín-

dice.

El campo Atributos especifica los atributos de cada objeto que será mostrado
en el índice. Los atributos que son usados para accesar el contexto (atributos selec-
tores) deben presentar un destino, o sea, los elementos que serán accesados a partir
del índice. Cuando varios selectores presentan el mismo destino, ellos son especifi-
cados en una lista donde los selectores son separados por coma (,).

El campo ordenación especifica el criterio de ordenación de los elementos del

índice. Cuando un contexto es jerárquico, deben ser especificados los criterios de
ordenación para los elementos de cada nivel de jerarquía.

El campo Restricciones de Uso especifica los diferentes permisos de acceso

al índice.

Los campos Depende de e Influencia presentan los elementos creados du-

rante el modelamiento que al ser modificados influencian en este índice o que son
influenciados por una modificación de este índice.
 87

A figura A1.24 presenta o cartas de estructura de acceso profesores presen-

tada en figura A1.21.

estructura de acceso: profesores Tipo: simples

parámetros:
Elementos: P: profesor
Atributos: Destino:
P.nombre P: profesor DONDE P pertenece-a profesor Alfa-
bético
P.título
P: profesor DONDE P pertenece-a profesor por
Título
ordenación: ORDENADO POR P.nombre, ASCENDENTE
Restricciones de Uso
usuario: lectores permiso: lectura
Comentarios:
Depende de: Influencia:
Figura A1.24 – Cartas de estructura de acceso profesores
 88

La figura A1.25 presenta las cartas de estructura de acceso jerárquica Profe-

sores: Áreas presentada en figura A1.22.

Estructura de acceso: profesores : Áreas Tipo: jerárquica

parámetros:
Elementos: profesores - p: profesor
Áreas - a: Área DONDE p actúa en a
Atribu- Destino:
tos:
Idx Áreas
profesores - p.nombre
a: Área DONDE a pertenece-a profesores por Área
Áreas -
A.nombre
ordenación: profesores - ORDENADO POR p.nombre, ASCENDENTE
Áreas - ORDENADO POR A.nombre, ASCENDENTE
Restricciones de Uso
usuario: lectores permiso: lectura
Comentarios:
Depende de: Influencia:
Figura A1.25 – Cartas de estructura de acceso profesores: Áreas

2.3 Clases en Contexto

Como no se pueden representar características diferentes dentro de diferentes

contextos, son creadas clases en contexto para definir la apariencia de los puntos
anclas (âncoras) de cada uno en cada contexto al cual él pertenece, como también
otras informaciones importantes del contexto. Una clase en el contexto solo es nece-
saria si tiene una apariencia diferente y puntos anclas (âncoras) distintos en el con-
texto en cuestión.

También son especificados en las clases del contexto los atributos multi-
valorados que no presentan perspectiva default, definidos en el esquema conceptual.
Cada perspectiva de un atributo multi-valorado debe ser mapeada para un atributo
en una clase en contexto.

Las clases en el contexto son representadas por una línea con flecha doble
conectando la clase en contexto a la clase navegacional (el) que está siendo adorna-
da por ella. La clase en contexto es representada por un rectángulo dividido en cua-
tro partes. La primera parte contiene su identificador. La segunda parte contiene los
atributos que están siendo adicionados a la clase. La tercera parte contiene las ope-
raciones que también están siendo adicionadas a la clase. La cuarta parte especifica
 89

los contextos en los cuales la clase en contexto participa. La figura A1.26 muestra
una representación gráfica de clase en contexto profesor por Área. Como esta clase
en contexto no presenta ninguna operación, o compartimiento que contiene las ope-
raciones fue excluida.

Profesor

classe: String
area-ind: índice (Área de Investigación por Profesor (self))
disciplinas: ancla (índice (Disciplina por Profesor (self))
estud: ancla (índice (Estudiantes por Profesor (self))
salario-base: Real

Profesor por Área

prox-prof: ancla (próximo (Profesor por Área (Área)))

ant-prof: ancla (anterior (Profesor por Área (Área)))

contexto Profesor por Área

Figura A1.26 – Clase en contexto profesor por Área
A continuación una definición de esquema de contextos navegacionales es
necesario definir también los diagramas presentando las clases especificadas en
contexto.
 90

2.4 Esquema de Contextos de Navegación

A figura A1.27 presenta parte de un esquema de contextos de navegación. En

ella son presentados algunos contextos de navegación y estructuras de acceso.

Profesor

Profesores Alfabético

por Área de Investigación

por Laboratorio

por Proyecto de
Investigación

Proyecto de Investigación
Menú Proyectos de
Principal Investigación Todos

por Profesor

por Laboratorio

Laboratorio

Laboratorios Alfabético

por Área de Investigación

Área de Investigación
Áreas de Investigación Alfabético

por Profesor

Figura A1.27 – Esquema de contextos de navegación

Observe que, en este ejemplo, son identificados los landmarks, i.e., los puntos
accesibles a partir cualquier objeto: Menú Principal, y los índices de profesores, Pro-
yectos de Investigación, laboratorios y Áreas de Investigación.
 91

Anexo 2: Diccionario de Datos del DER Integrado

Asociados a * relacionamiento entre Resultados de Búsqueda y Producto Consultado*
Busca * relacionamiento entre Visitante en Línea y Palabra Clave* (Nº de búsqueda en la sesión)
Búsqueda exitosa * subentidad de Criterio de búsqueda por categorías *
Búsqueda no exitosa * subentidad de Criterio de búsqueda por categorías *
Categoría @código categoría + nombre categoría
cd = * subentidad de Producto * 1{ artista } + sello + catálogo + { pista + ( duración ) } + ( duración total ) + for-
mato digital + número de unidades + { extracto }
cesta = @id cesta + estado cesta + ( nombre cesta )
clasificación = * relacionamiento entre Producto y Categoría *
cliente = @id cliente
cliente eventual = * subentidad de Cliente Registrado * [ dirección de despacho | dirección de regalo ]
cliente permanente = * subentidad de Cliente Registrado * 1{ [ dirección de despacho | dirección de regalo ] }
cliente registrado = * subentidad de Cliente * nombre cliente + ( correo electrónico ) + dirección personal + forma de pago +
código cliente + contraseña
consignación = * relacionamiento entre Pedido y Flete *
Consulta * relacionamiento entre Visitante en Línea y Consulta producto * (Nº de búsqueda en la sesión)
Consulta producto * registra las palabras ingresadas por los visitantes para buscar algún tipo de producto* @id consulta pro-
ducto
Consulta producto existosa * Consulta producto *
Consulta producto no exitosa * Consulta producto *
contenido = * relacionamiento entre Cesta y Producto * cantidad
courier = * subentidad de Empresa *
Criterio de búsqueda por * registra las palabras ingresadas por los visitantes para buscar algún tipo de producto por categoría* @id
categorías criterio
empresa = @RUT + razón social + dirección + 1{ fono } + { fax } + representante
flete = @id flete + tipo flete + cargo fijo + cargo variable
flete expreso = * subentidad de Flete *
inclusión = * relacionamiento entre Producto y Pedido * { estado producto + cantidad en estado } + cantidad producto
libro = * subentidad de Producto * 1{ autor } + { editor } + editorial + índice contenidos + ISBN + ( edición ) + (
reimpresión ) + ( formato encuadernación ) + ( número páginas ) + número volúmenes + { trozo }
Obtiene * relacionamiento entre Palabra Clave y Resultados de Búsqueda*
Palabra clave * registra las palabras ingresadas por los visitantes para buscar algún tipo de producto por búsqueda* @id
palabra clave
pedido = @número pedido + fecha + tipo despacho + estado pedido + autorización pago + fecha cierre
 92

Pedido Realizado * registra los pedidos consultados por los visitantes * (Fecha consulta)
pertenencia = * relacionamiento entre Cesta y Cliente *
Pregunta * relacionamiento entre Visitante en Línea y Pedido Realizado*
Producto @código producto + título + 1{ idioma }+ observaciones + disponibilidad + stock + foto + descuento + pre-
cio + año publicación + lugar publicación + { rol + comentario + ( evaluación ) } + posición de venta + posi-
ción de preferencia + cantidad vendida + promedio evaluaciones
Proveedor * subentidad de Empresa *
provisión = * relacionamiento entre Producto y Proveedor *
Realiza * relacionamiento entre Visitante en Línea y Sesión*
Resultado de la búsqueda * registra los resultados mostrados producto del ingreso de palabras por los visitantes para buscar algún
tipo de producto por búsqueda* @id resultado
Se asocia a * relacionamiento entre Consulta producto exitosa y producto *
Se relaciona * relacionamiento entre Búsqueda exitosa y Categoría *
servicio = * relacionamiento entre Expreso y Courier *
Sesión @id conexión + servidor + país + idioma local + hora local+fecha+hora inicio+hora cierre
solicitud = * relacionamiento entre Cliente y Pedido *
Tiene productos ingresados * relacionamiento entre Visitante en Línea y Cesta*
a
Utiliza * relacionamiento entre Visitante en Línea y Criterios de Búsqueda por categorías * (Nº de búsqueda en la
sesión)
video = * subentidad de Producto * 1{ director } + 1{ productor } + duración + { actor } + { narrador } + subtitulos +
sistema + número serie + número de unidades + reseña contenidos + { sinopsis }
Visitante en línea @id visitante + Fecha Sesión + Hora Sesión
 93

Anexo 3: Desarrollo de un caso

@id nombre @número @código cantidad Fecha
Fecha pedido artista autor director precio
cliente cliente pedido producto producto sesión
1 Ana 1 01-01-01 1 U2 1 5.000
17 Elsa 2 16-03-00 1 U2 2 5.000
2 Eva 3 01-01-00 2 Kalakota 1 10.000
9 Jorge 4 23-01-00 1 U2 1 5.000
1 Ana 5 23-01-00 2 Kalakota 1 10.000
3 Juan 6 02-01-00 3 Justiniano 1 15.000
4 Pablo 7 03-01-00 4 Joe Vasconcelos 1 4.500
3 Juan 8 23-01-00 1 U2 1 5.000
5 Ivo 9 02-01-00 2 Kalakota 1 10.000
12 John 10 13-01-00 3 Justiniano 2 10.000
1 Ana 11 03-01-00 4 Joe Vasconcelos 1 4.500
9 Jorge 12 03-01-00 1 U2 1 5.000
5 Ivo 13 04-01-00 5 Conallen 1 12.500
7 Tomas 14 02-01-00 2 Kalakota 1 10.000
8 Julio 15 03-01-00 3 Justiniano 1 10.000
9 Jorge 16 04-01-00 4 Joe Vasconcelos 1 4.500
6 Paula 17 05-01-00 6 Sting 1 10.000
4 Pablo 18 23-01-00 5 Conallen 1 12.500
8 Julio 19 02-01-00 3 Justiniano 1 10.000
16 Sonia 20 02-01-00 4 Joe Vasconcelos 1 4.500
7 Tomas 21 06-01-00 7 Peter Gabriel 1 8.500
7 Tomas 22 03-01-00 5 Conallen 1 12.500
3 Juan 23 11-05-00 3 Justiniano 2 10.000
11 Sergio 24 11-01-00 7 Peter Gabriel 1 8.500
17 Elsa 25 01-02-00 5 Conallen 1 12.500
8 Julio 26 07-01-00 8 Davenport 1 15.500
3 Juan 27 23-01-00 12-2-00
9 Jorge 28 08-01-00 9 Mussorgsky 2 6.000
3 Juan 29 02-01-00 7 Peter Gabriel 1 8.500
 94

@id nombre @número @código cantidad Fecha

Fecha pedido artista autor director precio
cliente cliente pedido producto producto sesión
14 Lucia 30 23-01-00 8 Davenport 1 15.500
3 Juan 31 23-01-00 12-2-00
13 Claudia 32 12-01-00 9 Mussorgsky 1 6.000
1 Ana 33 01-02-00 7 Peter Gabriel 1 8.500
10 Pedro 34 09-01-00 6 Sting 1 10.000
19 Luis 35 23-01-00 8 Davenport 1 15.500
6 Paula 36 02-01-00 22-1-00
16 Sonia 37 25-02-00 9 Mussorgsky 1 6.000
8 Julio 38 19-08-00 7 Peter Gabriel 1 8.500
1 Ana 39 03-02-00 6 Sting 1 10.000
5 Ivo 40 16-11-06 8 Davenport 1 15.500
3 Juan 41 23-01-00 12-2-00
18 Helga 42 06-01-00 9 Mussorgsky 1 6.000
8 Julio 43 03-01-00 7 Peter Gabriel 1 8.500
7 Tomas 44 19-08-00 6 Sting 1 10.000
18 Helga 45 18-11-00 8 Davenport 1 15.500
6 Paula 46 23-01-00 12-2-00
20 Talia 47 03-02-00 9 Mussorgsky 2 6.000
3 Juan 48 11-05-01 7 Peter Gabriel 1 8.500
3 Juan 49 23-01-00 6 Sting 1 10.000
4 Pablo 50 12-01-00 8 Davenport 1 15.500
6 Paula 51 02-01-00 22-1-00
1 Ana 52 19-08-00 9 Mussorgsky 1 6.000
 95

Apéndice 1: Sistema de Ventas On-Line

www.marraqueta.cl 3

1 Antecedentes

Un grupo de ingenieros comerciales, industriales e informáticos recién egre-

sados (IIC Ltda.) dijeron ¡basta! a los vendedores extranjeros vía Internet y decidie-
ron instalar su propio sitio denominado www.marraqueta.cl (A la fecha, este dominio
no tiene aun su servidor de nombres propio), para vender los tipos de productos que
más se transan electrónicamente: libros, CD’s y videos, todos de procedencia legal y
preferentemente de producción nacional. La idea es que en el mediano plazo pueda
diversificarse la oferta y entregar más productos nacionales. Los socios decidieron
darle un fuerte distintivo nacional al sitio y a los productos ofrecidos, pero con un ser-
vicio world class. Consideran que un porcentaje significativo de los clientes debieran
ser extranjeros o chilenos radicados en el exterior, los cuales están acostumbrados a
altos niveles de calidad en los servicios que contratan.
El nombre del sitio fue adoptado por ser la marraqueta (pan batido o francés)
uno de los alimentos más recordados y anhelados por los chilenos que viven en el
exterior, y de mayor aceptación por los extranjeros que visitan el país.
Los ingenieros de IIC aplicaron sus conocimientos y decidieron realizar un
benchmarking para “copiar” las buenas ideas de algunos de los grandes y exitosos
del comercio electrónico. Amazon.com, CDNow, Borders.com, Barnes&Noble y Be-
yond.com fueron algunos de los sitios web cuidadosamente analizados para extraer
principios que orientaran el diseño del similar chileno.
Los aspectos estéticos nacionalistas fueron entregados a una pequeña em-
presa de diseño gráfico computacional, cuyos socios eran conocidos de IIC.
El financiamiento pudo conseguirse con algunos ahorros, aportes mayores de
algunos familiares y una cuenta de publicidad para las páginas del sitio web. La in-
versión es relativamente pequeña en personal, local, equipamiento, software, servi-
cios contratados de conexión a Internet, publicidad en revistas especializadas y en
buscadores de Internet y capital para inventario.

3
Este problema fue realizado en la asignatura de Sistemas de Información del Segundo semestre de
1999 en la Escuela de Ingeniería Industrial de la UCV.
 96

2 Sistema de Información a Ser Modelado

El sistema a ser modelado debe dar apoyo al servicio al cliente, para que éste
pueda navegar libremente recopilando información muy variada sobre los productos
que desea comprar en el sitio web, ofrecerle la opción de poder adquirir los produc-
tos deseados y permitirle monitorear el estado de avance de su pedido hasta su des-
pacho. Además, este sistema debe permitir obtener información sobre el comporta-
miento global de los compradores para planificar las compras, campañas de des-
cuentos, oferta a los clientes y otros.

Los productos comercializados electrónicamente son videos (documentales,

musicales, películas), CD’s (de cualquier género musical) y libros (de cualquier géne-
ro literario). Como se desea vender en forma virtual, éstos deben contar con la mayor
cantidad de datos posibles para que el cliente pueda decidir informadamente. Esto
incluye una foto de la portada del video, CD o libro. La tabla 1 muestra los datos bá-
sicos para cada tipo de producto.

Tabla 1 – Datos básicos para cada tipo de producto.

VIDEO CD LIBRO
• título • título • título
• director(es) • artista(s) (o compositor(es) e • autor(es) o editor(es)
• productor(es) intérprete(s)) • editorial
• año y lugar de publicación • sello • año y lugar de publicación
• duración • Nº de catálogo • índice de contenidos
• actores y/o narradores • año y lugar de la publicación • ISBN (International Standard
• idioma(s) • idioma(s) Book Number)
• con/sin subtítulos • lista de pistas y duración • idioma(s)
• color/blanco&negro individual • edición
• sistema de reproducción • duración total • reimpresión
(Pal-N, Pal-M, NTSC) • formato digital (AAD, ADD, • categoría(s) a las que perte-
• Nº de serie DDD) nece
• Nº de unidades • categoría(s) a las que perte- • formato de encuadernación
• categoría(s) a las que perte- nece • Nº de páginas
nece • Nº de unidades • Nº de volúmenes
• reseña de contenidos • observaciones • observaciones
• observaciones

Es importante destacar que, dado lo cambiante del mercado de estos 3 tipos

de productos, las clasificaciones deben ser abiertas y con posibilidad de combinar
sus categorías. Así por ejemplo, un CD de Inti Illimani puede ser clasificado como
folclórico-andino y popular-vocal-romántico-bolero al mismo tiempo, y si esto termina
creando un género híbrido, el sistema deberá permitir su inclusión posterior, como
por ejemplo vanguardia-fusión-raíz nativa.
 97

Aprovechando las posibilidades que ofrece Internet, se desea implementar

también la posibilidad de entregar sinopsis de los videos, extractos de pistas de los
CD y trozos de los libros para que los clientes tengan aún más información sobre el
producto que desea comprar4. Inicialmente, sólo un porcentaje pequeño de los pro-
ductos tendrá esta opción, pero a medida que el negocio crezca y se pueda invertir
en mayores capacidades de los servidores y de comunicación, esto debería generali-
zarse.

Uno de los principios de diseño del servicio es entregar la posibilidad de crear

una cuenta individual gratuita por cliente, donde consten sus datos personales, como
nombre, correo electrónico, dirección personal, direcciones de despacho, direcciones
para regalos y formas de pago (cheque US$, tarjeta de crédito o depósito en cuenta
bancaria). Esta cuenta es personal y debe tener mecanismos de seguridad como
contraseña y encriptación para el acceso y almacenamiento.

Gracias a la tecnología web, es posible ofrecer al cliente la navegación sobre

los diferentes productos a la venta y que éste sea capaz de agregarlos a una cesta
de compras. Alternativamente, el cliente puede almacenar productos en diferentes
cestas bastando para ello que él las denomine distintamente. Los productos en estas
cestas pueden ser posteriormente removidos o sus cantidades modificadas, dentro
del proceso de pasar a caja. La búsqueda se puede hacer por cualquiera de los da-
tos asociados a cada producto. Eso sí, el cliente debe indicar cuál es el tipo de pro-
ducto buscado. Cada resultado de una búsqueda le debe dar la posibilidad de ver
otros productos relacionados (usando los vínculos de las páginas) por direc-
tor/productor/artista/autor. Por ejemplo, si el cliente buscó un libro sobre Violeta Pa-
rra, debería poder ver también los videos y los CD’s que tengan relación con ella.

En el proceso de pasar a caja, el cliente debe individualizarse, si es que no lo

ha hecho previamente. Si es un cliente nuevo, se le deberá ofrecer la posibilidad de
crear una cuenta en este momento o se le puede dar la opción de ser cliente even-
tual, el cual sólo entrega datos para hacer su compra sin que se cree una cuenta in-
dividual. Con la cuenta individualizada, el cliente debe confirmar los datos sobre la
forma de pago, la dirección para el despacho y si corresponde a un regalo. Luego se
le indica el valor total de los productos y del flete correspondiente5. Seguidamente, el
cliente debe indicar si desea se le despache todos los productos juntos o de acuerdo
a la disponibilidad6 (en este último caso el flete total es más caro, porque cada vez se

4
El pago de derechos de autor no constituye un costo apreciable para esta modalidad de divulgación
de las obras.
5
El flete se calcula en base a un valor fijo y un valor por ítem, y bajo 2 modalidades: normal y expresa.
Ambas modalidades tienen valores distintos dependiendo de las zonas: Zona nacional 1 = Región
Metropolitana; Zona nacional 2 = III, IV, V, VI, VII, VIII y IX regiones; Zona nacional 3 = I, II, X, XI y XII;
Zona nacional 4 = Chile insular occidental; Zona internacional 1 = Sudamérica; Zona internacional 2 =
Centro y Norteamérica; Zona internacional 3 = Europa occidental y Africa; Zona internacional 4 = Me-
dio Oriente y Europa Oriental; y Zona internacional 5 = Asia y Oceanía.
6
La disponibilidad está dividida en 1-2 días, 7-10 días y 21-30 días. Algunos productos tienen disponi-
bilidad desconocida, porque son pedidos especialmente.
 98

calcula el flete como si el despacho parcial fuera un pedido). El pedido es numerado

únicamente y se agrega al historial de pedidos del cliente registrado.

Los pedidos realizados durante un día son procesados el día hábil siguiente
en la sección Solicitud a Proveedores de IIC, donde son ordenados los pedidos a los
proveedores correspondientes, si es que los productos no se encuentran en bodega.
En general, los niveles de stock son bajos, pero a través de convenios especiales
con proveedores se logra bajar los costos de adquisición con plazos de entrega bre-
ves. Si el pedido es de acuerdo a disponibilidad, y la sección de Finanzas da su auto-
rización, los productos son despachados al día hábil siguiente. Si el pedido es de
despacho total, éste se almacena en bodega en espera de completarse. Si el pedido
no se completa en 60 días, éste es despachado y los restantes productos son cance-
lados7. Los productos de disponibilidad desconocida pueden esperar hasta 120 días.
En el momento del despacho del pedido, se informa a Finanzas sobre el mismo para
hacer efectivo el pago.

Usando su cuenta individual, el cliente debe poder revisar el estado de todos

los pedidos realizados, incluyendo los que aún estén en proceso. Si el cliente quiere,
puede cancelar total o parcialmente un pedido que no se encuentre aún en bodega,
es decir, los productos solicitados que aún no hayan sido recibidos de los proveedo-
res pueden cancelarse. Lo cual obliga a definir claramente cuál son las etapas por
las que pasa cada producto, desde que es solicitado por el cliente hasta que le es
despachado. Cada avance de etapa debe ser actualizada por las secciones involu-
cradas, de tal modo que se reflejen inmediatamente en el sitio web.

A los datos indicados de cada tipo de producto, el cliente registrado y el even-

tual puede agregar comentarios clasificados en 3 categorías: como productor del vi-
deo/CD o editor del libro, como director/artista del video/CD o autor del libro y como
espectador/auditor/lector del producto. Estos comentarios, tanto positivos como ne-
gativos, enriquecen los productos con información para futuros compradores. En la
modalidad espectador/auditor/lector debe entregarse además una evaluación en una
escala de 1 a 10.

Con todos los datos disponibles de los pedidos hechos por los clientes, es po-
sible generar información para los propios clientes como para la gestión del negocio.
Inicialmente se puede entregar un ranking de ventas, es decir, indicar para cada pro-
ducto su posición relativa en el volumen de ventas del tipo de producto. Cada pro-
ducto puede ir acompañado de esta información cuando presentado al cliente, como
así también se le debe proporcionar navegación sobre los top 100 más vendidos de
la lista de videos, CD’s y libros. Lo mismo ocurre con la evaluación hecha por los
clientes, que permite construir un ranking de preferencias de los clientes, en base al
promedio de las evaluaciones por producto. La lista de los top 100 mejor evaluados
por cada tipo también debe ser navegable. Asimismo, con el historial de pedidos es

7
Si el proveedor no informa que el producto ha sido descontinuado, esto significa alterar la disponibili-
dad del producto al plazo 21-30 días o desconocida, según sea el caso.
 99

posible proporcionar información sobre productos que son comprados juntos más
frecuentemente. Por ejemplo, un determinado cliente desea comprar un video sobre
aves chilenas de Sergio Nuño, y el sistema le puede sugerir un video Al Sur del
Mundo de Francisco Gedda, un CD sobre canto de aves chilenas y libros de fotogra-
fías de naturaleza nativa, porque existen pedidos anteriores donde el video de Nuño
se había comprado con 1 o más de estos otros productos.

La generación de los rankings y los productos asociados, así como informa-

ción sobre los volúmenes de venta totales, por tipo de producto, por producto y por
cliente, son muy útiles para dirigir ofertas y descuentos para los clientes, negociar
convenios con los proveedores de los distintos productos y con las empresas de cou-
rier y desarrollar, en general, estrategias para el negocio.
 100

3 Solución

Convenciones, Observaciones y Supuestos del Problema

§ Convención de notación para las Especificaciones de Proceso:

Elemento negrita minúscula MAYÚSCULAS

elementos del DD (a excepción de los depósitos) a a
DEPÓSITOS a a
instrucciones (PARA, SI, CASO, etc.) a a
acciones (INCREMENTAR, ACCESAR, EMITIR, etc.) a
variables locales de los procesos a a

§ Cliente posee instancias de clientes registrados y clientes anónimos. Clientes

anónimos son aquellos que han pasado a caja o no se han registrado hasta el
momento. Además se entiende por clientes anónimos a aquellos cuyos pedidos
han sido despachados, por lo que se mantiene una instancia en Cliente que los
representa para que la empresa pueda saber cuáles pedidos ya fueron despa-
chados.

§ La primera cesta de cada cliente es siempre no identificada. Por lo tanto, si el

cliente se va y no la identifica, entonces esta cesta es eliminada.

§ Las personas que sólo navegan por la página de Marraqueta, no están individua-
lizadas por la empresa y no se representan en el sistema.

§ No existe un stock mínimo para cada artículo. Si el stock en bodega es mayor que
la cantidad solicitada en un pedido, entonces se reduce el stock disponible y se
satisface el pedido. Si el stock es menor que la cantidad, entonces se emite una
orden a proveedor.

§ Se entiende actualizar en general, como agregar un elemento nuevo o modificar

uno existente dentro del depósito.

§ Se entiende por concurrencia como el procesamiento de multi-instancias, pero

cada una de ellas en un proceso diferente. Si se quisiera modelar multi-instancias
para cada proceso, entonces se debería usar redes de Petri compactas.

§ Una cesta puede ser identificada en cualquier momento, mediante el proceso de

Asignar nombre a cesta.
 101

Modelamiento Dinámico:

§ Red de Petri jerarquizada (red canal/actividad)

§ Red de Petri elemental
 102

(1) (2) (3)

Espera
Espera Espera
recepción
categoría comentario
de compra

Actualización de Adición de Actualización de

categorías comentarios stock

(4) (5) (6)

Espera Espera Espera

provisión producto cesta

Actualización de Adición de Nominación de

provisión producto a cesta cesta

(7) (8) (9)

Espera Espera Espera top

flete pedido 100

Actualización de Consulta por Consulta por top

fletes pedido 100
 103

(10)

Espera tipo
producto

Actualización de Actualización de Actualización de

CD's libros videos

(11)
Espera
producto
Espera
palabra

Interfaz de
búsqueda y (12)
descripción del
producto
Espera
periodo

Búsqueda y Descripción
descripción adicional del
del producto producto
Generación de
volúmenes de
venta

Actualización de
rankings y
productos
asociados
 104

(13)

Espera
revisión

Interfaz de revisión
Cancelamiento de
y despacho de
producto
pedidos

Revisión y
verificación
de stock y
disponibilidad

(14)

Espera
cesta

Actualización de Eliminación de
cliente cesta

Pase a caja
 105

(1)
(2)

esperando
categoría a esperando
actualizar producto
comentado

categoría a
actualizar categoría producto comentario
recibida actualizada comentado agregado
recibido

actualizando agregando
categoría comentarios

(3)
(4)

esperando esperando
recepción de provisión a
compra actualizar

recepción de stock provisión a provisión

compra recibida actualizado actualizar actualizada
recibida

actualizando actualizando
stock provisión
 106

(5) (6)

esperando
esperando
identificación
identificación de
producto
cesta a nombrar

identificación producto identificación de nombre

producto agregado a cesta a nombrar cesta
recibida cesta recibida asignado

agregando asignando nombre

producto a a cesta
cesta

(7)
(8)
esperando
flete a esperando
actualizar identificación
pedido

flete a
fletes
actualizar identificación status pedido
actualizados
recibido pedido recibida emitido

actualizando consultando
fletes pedido
 107

(9)

esperando top
100 solicitado

top 100
solicitado
recibido
top 100 CDs
emitido consultando
top 100

top 100 videos

emitido
top 100 libros
emitido

(10)
esperando
producto a
actualizar
esperando CD esperando libro esperando video a
a actualizar a actualizar actualizar

CD a libro a video a
actualizar actualizar actualizar
recibido recibido recibido

actualizando actualizando actualizando

CD libro video

CD libro video
actualizado actualizado actualizado
 108

(11)
esperando
palabra

palabra mayor descripción

búsqueda descripción del producto
recibida terminada terminada terminada

describiendo más
del producto

buscando
producto actualizaciones
terminadas
lista
productos actualizando
emitida rankings
esperando
descripción

esperando
selección actualizando
productos
descripción asociados
producto producto a
producto
seleccionado describir
emitida
recibido finalizado

describiendo
producto

(12)

esperando
periodo

generando generando
volúmenes de volúmenes de
ventas por ventas por tipo
cliente producto
periodo
recibido
ventas por tipo
ventas por producto
cliente emitida emitida
fin generación
volúmenes de
ventas generación de
generación de ventas por tipo
ventas por producto
cliente terminada
terminada
 109

(13)
esperando revisar
stock

revisión stock despacho de

terminada pedidos terminado

lista de despachos
inicio emitida despachando
revisar pedidos
stock despacho y aviso
pago emitidos

revisando recepción de
stock mensaje en stock emitida
proceso emitido

identificación producto verificación de

pedido en proceso disponibilidad terminada
sin stock emitida
emitido

verificando verificando
recepción disponibilidad
de stock

identificación producto
producto cancelándose
cancelado
recibida identificación
verificación de producto a
recepción de cancelar
stock terminada cancelando recibida
producto

cancelamiento producto cancelado

producto emitido
terminado
pedido cancelado
emitido
 110

(14)

esperando
identificación identificación
cesta cesta
recibida

esperando
pasando a inicio
cliente a
caja actualización
actualizar
cliente

cliente
actualizando cliente a actualizándose
cliente actualizar
recibido

fin actualización
cliente

detalle pedido
emitido

cesta
esperando
eliminándose
identificación
cesta pasada
a caja

identificación cesta
pasada a caja
recibida
identificación cesta
para eliminar
recibida

eliminando
cesta

cesta eliminada

eliminación
cesta
terminada
 111

(1)
ACTUALIZACIÓN (2) ADICIÓN DE
DE CATEGORÍAS COMENTARIOS
esperando
categoría a esperando
actualizar producto
comentado

categoría a
actualizar categoría producto comentario
recibida actualizada comentado agregado
recibido

actualizando
categoría agregando
comentarios

(3) (4)
ACTUALIZACIÓN ACTUALIZACIÓN
DE STOCK DE PROVISIÓN
esperando esperando
recepción de provisión a
compra actualizar

recepción de stock provisión a

provisión
compra recibida actualizado actualizar
actualizada
recibida

actualizando actualizando
stock provisión
 112

(5) ADICIÓN DE (6)

PRODUCTO A CESTA NOMINACIÓN
DE CESTA

esperando
esperando
identificación
identificación de
producto
cesta a nombrar

identificación producto identificación de nombre

producto agregado a cesta a nombrar cesta
recibida cesta recibida asignado

agregando asignando nombre

producto a a cesta
cesta

(7) ACTUALIZACIÓN (8) CONSULTA

DE FLETES POR PEDIDO

esperando esperando
flete a identificación
actualizar pedido

flete a
fletes identificación status pedido
actualizar
actualizados pedido recibida emitido
recibido

actualizando consultando
fletes pedido
 113

(9) CONSULTA
POR TOP 100

esperando top
100 solicitado

top 100
solicitado
recibido

top 100 CDs consultando

emitido top 100

top 100 videos

emitido
top 100 libros
emitido

(10) ACTUALIZACIÓN
DE PRODUCTOS esperando
producto a
actualizar
esperando CD esperando libro esperando video a
a actualizar a actualizar actualizar

CD a libro a video a
actualizar actualizar actualizar
recibido recibido recibido

actualizando actualizando actualizando

CD libro video

CD libro video
actualizado actualizado actualizado
 114

(11) BÚSQUEDA Y DESCRIPCIÓN

DE PRODUCTOS

esperando
palabra
mayor descripción
del producto
terminada
palabra
recibida descripción
terminada
describiendo
más del
producto

buscando búsqueda actualizando

producto terminada rankings

actualizaciones
lista productos terminadas
emitida

esperando
esperando descripción
selección descripción
producto producto a actualizando
describiendo emitida describir productos
producto finalizado asociados
producto
seleccionado
recibido

(12) GENERACIÓN DE
VOLÚMENES DE VENTA

esperando
periodo

generando generando
volúmenes de volúmenes de
ventas por ventas por tipo
cliente producto
periodo
recibido
ventas por tipo
ventas por producto
cliente emitida emitida
fin generación
volúmenes de
ventas generación de
generación de ventas por tipo
ventas por producto
cliente terminada
terminada
 115

(13) PROCESAMIENTO
DE PEDIDOS

esperando revisar stock

inicio revisión
despacho de
revisar stock
pedidos terminado
stock terminada

revisando despachando
stock pedidos

lista de despachos
emitida

despacho y aviso
pedido en proceso pago emitidos
emitido

verificando
recepción recepción de
mensaje en stock emitida
de stock proceso emitido

verificación de
verificando
disponibilidad terminada
disponibilidad
verificación de recepción
de stock terminada

identificación producto identificación producto

cancelado recibida sin stock emitida

cancelando producto
producto cancelándose

identificación
producto a
cancelar
cancelamiento recibida
producto terminado

producto
pedido
cancelado emitido
cancelado
emitido
 116

(14) PASE A
CAJA
esperando
identificación
cesta

identificación
cesta
recibida

inicio
actualización
esperando cliente
pasando a
cliente a
caja
actualizar
cliente
actualizándose

cliente a
actualizar
detalle pedido recibido
emitido

fin
actualización
cliente
actualizando
esperando
cliente
identificación
cesta pasada
a caja cesta
eliminándose
identificación cesta
identificación
pasada a caja
cesta para
recibida
eliminar
recibida

eliminando
cesta
cesta
eliminada

eliminación cesta
terminada
 117

Modelamiento Estático:

§ Modelo Clusterizado Entidad-Relacionamiento

§ Modelo Entidad-Relacionamiento
§ Diccionario de Datos
 118

Categoría

Empresa

{ dominancia }
Cliente

{ dominancia }

(1, n) clasifica-
Categoría Empresa
ción

(1, n) { abstracción }

Producto

{ abstracción }

Cliente Flete

{ dominancia } { abstracción }
 119

(1, n) clasifica-
Categoría Empresa
ción

(1, n)
{ abstracción }
pertenen- (0, n) (0, n) (1, n) (1, n)
Cesta contenido Producto
cia

inclusión
{ abstracción }

(0, 1)
(0, n)

(0, n)
Cliente solicitud Pedido
(1, 1)

(0, n)

{ abstracción } consigna-
Flete
(1, 1) ción

{ abstracción }
 120

Empresa

(t, e)

(1, n) clasifica- (1, n) (1, 1)

Categoría provisión Proveedor Courier
ción

(1, 1)
(1, n)

pertenen- (0, n) (0, n) (1, n) (1, n)

Cesta contenido Producto
cia

(t, e)
inclusión
(0, 1)

(1, 1) Cd Libro Video

Cliente
servicio

(0, n)

Cliente (0, n)
solicitud Pedido
Registrado

(t, e) (0, n)

(1, 1) consigna-
Flete
ción
Cliente Cliente
Eventual Permanente

Flete Expreso
(1, n)
 Diccionario de Datos

autorización pago = * autorización recibida para cada pedido desde finanzas; valores [ Si | No ] *
aviso pago = número pedido + monto + fecha
cancelamiento pedido = * se indica que el pedido ha sido cancelado porque su(s) producto(s) ha(n) excedido el plazo de entrega co-
rrespondiente *
cancelamiento producto = * se indica que el producto ha sido cancelado del pedido por haber excedido el plazo de entrega correspon-
diente *
categoría = @código categoría + nombre categoría
categoría a actualizar = código categoría + nombre categoría
categorías = { categoría }
cd = * subentidad de Producto * 1{ artista } + sello + catálogo + { pista + ( duración ) } + ( duración total ) + formato
digital + número de unidades + { extracto }
cd a actualizar = [ cd modificado | cd nuevo ]
cd modificado = { artista } + ( sello ) + ( catálogo ) + { pista + ( duración ) } + ( duración total ) + ( formato digital ) + ( número de
unidades ) + { extracto }
cd nuevo = 1{ artista } + sello + catálogo + { pista + ( duración ) } + ( duración total ) + formato digital + número de unida-
des + { extracto }
cds = { cd }
cesta = @id cesta + estado cesta + ( nombre cesta )
cestas = { cesta }
clasificación = * relacionamiento entre Producto y Categoría *
cliente = @id cliente
cliente a actualizar = [ cliente modificado | cliente nuevo ]
cliente eventual = * subentidad de Cliente Registrado * [ dirección de despacho | dirección de regalo ]
cliente modificado = id cliente + ( nombre cliente ) + ( correo electrónico ) + ( dirección personal ) + ( forma de pago ) + { [ dirección
de despacho | dirección de regalo ] } + ( código cliente ) + ( contraseña )
cliente nuevo = nombre cliente + ( correo electrónico ) + dirección personal + forma de pago + 1{ [ dirección de despacho |
dirección de regalo ] } + código cliente + contraseña
cliente permanente = * subentidad de Cliente Registrado * 1{ [ dirección de despacho | dirección de regalo ] }
cliente registrado = * subentidad de Cliente * nombre cliente + ( correo electrónico ) + dirección personal + forma de pago + código
cliente + contraseña
clientes = { cliente }
clientes eventuales = { cliente eventual }
clientes permanentes = { cliente permanente }
clientes registrados = { cliente registrado }
consignación = * relacionamiento entre Pedido en Proceso y Flete *
contenido = * relacionamiento entre Cesta y Producto * cantidad
contenidos = { contenido }
 122

courier = * subentidad de Empresa *

courier modificado = empresa modificada
courier nuevo = empresa nueva
couriers = { courier }
descontinuación = * se indica que el producto no está más disponible para la compra *
descripción avanzada = lugar ranking ventas + lugar ranking preferencias + productos asociados + [ { extracto } | { sinopsis } | { trozo } ]
descripción producto = producto + [ cd | video | libro ]
despacho = id cliente + nombre cliente + dirección personal + [ dirección de despacho | dirección de regalo ] + número
pedido + tipo despacho + 1{ código producto + título + precio + cantidad + subtotal } + total productos + valor
tipo flete + total pago
detalle pedido = despacho + forma de pago
disponibilidad = * disponibilidades de entrega de los productos; valores [ 1-2 días | 7-10 días | 21-30 días | desconocida | dis-
continuada ] *
empresa = @RUT + razón social + dirección + 1{ fono } + { fax } + representante
empresa modificada = RUT + ( razón social ) + ( dirección ) + { fono } + { fax } + ( representante )
empresa nueva = RUT + razón social + dirección + 1{ fono } + { fax } + representante
empresas = { empresa }
estado cesta = * define si una cesta puede (activa) o no (no activa) recibir productos; valores [ activa | no activa ] *
estado pedido = * define en qué estado se encuentra un pedido con base en los productos que incluye; valores [ solicitado | en
proceso | cerrado ] *
estado producto = * define en qué estado se encuentra un producto en un pedido[ solicitado | en stock | en tránsito | cancelado |
despachado ]
evaluación = * calificación de un producto hecha por los clientes; valores [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 ] *
fecha de inicio = * fecha inicial para un periodo de consulta *
fecha de término = * fecha final para un periodo de consulta *
flete = @id flete + tipo flete + cargo fijo + cargo variable
flete a actualizar = [ flete nuevo | flete modificado ]
flete expreso = * subentidad de Flete *
flete modificado = ( courier modificado ) + id flete + ( tipo flete ) + ( cargo fijo ) + ( cargo variable )
flete nuevo = ( courier nuevo ) + id flete + tipo flete + cargo fijo + cargo variable
fletes = { flete }
forma de pago = [ cheque US$ | depósito en cuenta bancaria | tarjeta de crédito ]
formato digital = * tipos de grabación, mezcla y masterización (A=Análogo y D=Digital), respectivamente, indicada en los CD;
valores [ AAD | ADD | DDD ] *
foto = * imagen de la portada del producto *
identificación cesta = id cesta + tipo flete + tipo despacho
identificación cesta a nombrar = id cesta + nombre cesta
identificación cesta para eliminar = id cesta
identificación cesta pasada a caja = id cesta
 123

identificación pedido = número pedido

identificación producto = código producto + ( [ id cliente | id cesta ] )
identificación producto a cancelar = identificación producto en pedido
identificación producto cancelado = identificación producto en pedido
identificación producto en pedido = número pedido + código producto
identificación producto sin stock = identificación producto en pedido
inclusión = * relacionamiento entre Producto y Pedido * { estado producto + cantidad en estado } + cantidad producto
inclusiones = { inclusión }
libro = * subentidad de Producto * 1{ autor } + { editor } + editorial + índice contenidos + ISBN + ( edición ) + ( reim-
presión ) + ( formato encuadernación ) + ( número páginas ) + número volúmenes + { trozo }
libro a actualizar = [ libro modificado | libro nuevo ]
libro modificado = { autor } + { editor } + ( editorial ) + ( índice contenidos ) + ( ISBN ) + ( edición ) + ( reimpresión ) + ( formato
encuadernación ) + ( número páginas ) + ( número volúmenes ) + { trozo }
libro nuevo = 1{ autor } + { editor } + editorial + índice contenidos + ISBN + ( edición ) + ( reimpresión ) + ( formato encua-
dernación ) + ( número páginas ) + número volúmenes + { trozo }
libros = { libro }
lista de despachos = 1{ número pedido }
lista productos = tipo producto + palabra buscada + código producto + título + disponibilidad + precio + año publicación
mensaje pedido despachado = correo electrónico + despacho
mensaje pedido en proceso = correo electrónico + número pedido + estado pedido + fecha actual
mensaje pedido solicitado = correo electrónico + detalle pedido
palabra = tipo producto + palabra buscada
pedido = @número pedido + fecha + tipo despacho + estado pedido + autorización pago + fecha cierre
pedido cancelado = número pedido + fecha + fecha cierre + cancelamiento pedido
pedido en proceso = número pedido
pedidos = { pedido }
periodo = fecha de inicio + fecha de término
pertenencia = * relacionamiento entre Cesta y Cliente *
producto = @código producto + título + 1{ idioma }+ observaciones + disponibilidad + stock + foto + descuento + precio +
año publicación + lugar publicación + { rol + comentario + ( evaluación ) } + posición de venta + posición de
preferencia + cantidad vendida + promedio evaluaciones
producto a actualizar = [ producto nuevo | producto modificado ]
producto a describir = código producto
producto asociado = @código producto + 1{ código producto asociado + frecuencia }
producto cancelado = número pedido + código producto + título + cancelamiento producto
producto comentado = rol + código producto + comentario
producto modificado = código producto + ( título ) + { idioma }+ ( observaciones ) + ( disponibilidad ) + ( foto ) + ( descuento ) + ( pre-
cio ) + ( año publicación ) + ( lugar publicación ) + { rol + comentario + ( evaluación ) } + { nombre categoría }
 124

producto nuevo = código producto + título + 1{ idioma }+ observaciones + disponibilidad + foto + descuento + precio + año publi-
cación + lugar publicación + { rol + comentario + ( evaluación ) } + 1{ nombre categoría } + 1{ nombre categoría
}
producto seleccionado = código producto
productos = { producto }
productos asociados = * depósito de implementación relacionado con productos * { producto asociado }
productos descontinuados = 1{ código producto + título + descontinuación }
proveedor = * subentidad de Empresa *
proveedor modificado = empresa modificada
proveedor nuevo = empresa nueva
proveedores = { proveedor }
provisión = * relacionamiento entre Producto y Proveedor *
provisión a actualizar = [ provisión nueva | provisión modificada ]
provisión modificada = proveedor modificado + { código producto }
provisión nueva = proveedor nuevo + 1{ código producto }
recepción de compra = código producto + cantidad recibida + ( disponibilidad )
reposición de stock = 1{ código producto + cantidad solicitada }
rol = * define el rol de quien hizo el comentario de un producto, en el caso de ser un consumidor, se acompaña una
evaluación del producto; valores [ como productor | como autor | como consumidor + evaluación ] *
servicio = * relacionamiento entre Expreso y Courier *
sistema = * tipos de codificación de la señal de video usadas en el mundo; valores [ NTSC | Pal-M | Pal-N ] *
solicitud = * relacionamiento entre Cliente y Pedido *
solicitud de compra = RUT + razón social + 1{ código producto + cantidad a comprar }
status pedido = número pedido + 1{ código producto + título + precio + { cantidad en estado + estado producto } + cantidad
producto } + estado pedido
subtítulos = * define si el video cuenta o no con subtítulos; valores [ con | sin ] *
tipo despacho = * define la forma en que el cliente quiere se le despache su pedido, si es de acuerdo a disponibilidad o debe
despacharse todos los productos de una sola vez (total); valores [ disponibilidad | total ] *
tipo flete = [ zona nacional | zona internacional ]
tipo producto = * indica cuál es el tipo del producto; valores [ tipo cd | tipo video | tipo libro ] *
top 100 CDs = top 100 ventas + top 100 preferencias
top 100 libros = top 100 ventas + top 100 preferencias
top 100 preferencias = 1{ posición de preferencia + título + promedio evaluaciones }100
top 100 solicitado = tipo producto
top 100 ventas = 1{ posición de venta + título + cantidad vendida }100
top 100 videos = top 100 ventas + top 100 preferencias
ventas por cliente = periodo + cliente + cantidad vendida CDs + cantidad valorada CDs + cantidad vendida libros + cantidad valo-
rada libros + cantidad vendida videos + cantidad valorada videos + total valorado vendido por cliente } + total
 125

valorado vendido
ventas por producto = { código producto + cantidad vendida en periodo + cantidad valorada en periodo }
ventas por tipo producto = periodo + ventas totales CDs + ventas totales libros + ventas totales videos + total valorado vendido
ventas totales CDs = venta por producto + cantidad total CDs + total valorado CDs
ventas totales libros = venta por producto + cantidad total libros + total valorado libros
ventas totales videos = venta por producto + cantidad total videos + total valorado videos
video = * subentidad de Producto * 1{ director } + 1{ productor } + duración + { actor } + { narrador } + subtitulos + sis-
tema + número serie + número de unidades + reseña contenidos + { sinopsis }
video a actualizar = [ video modificado | video nuevo ]
video modificado = { director } + { productor } + ( duración ) + { actor } + { narrador } + ( subtitulos ) + ( sistema ) + ( número serie )
+ ( número de unidades ) + ( reseña contenidos ) + { sinopsis }
video nuevo = 1{ director } + 1{ productor } + duración + { actor } + { narrador } + subtitulos + sistema + número serie + núme-
ro de unidades + reseña contenidos + { sinopsis }
videos = { video }
volumen ventas = ventas por tipo producto + ventas por cliente
zona internacional = * define las zonas internacionales de envío para los efectos de cálculo del flete del pedido; valores [ 1-
Sudamérica | 2-Centro y Norte América | 3-Europa Occidental y Africa | 4-Medio Oriente y Europa Oriental | 5-
Asia y Oceanía ]*
zona nacional = * define las zonas nacionales de envío para los efectos de cálculo del flete del pedido; valores [ 1-Región Me-
tropolitana | 2-III a IX Regiones | 3-I, II, X a XII Regiones | 4-Insular Occidental ] *
 126

Modelamiento Funcional:

§ Diagramas de Flujo de Datos Nivelados

§ Especificaciones de Proceso
 127

Diagrama de contexto
Identificación cesta a nombrar Identificación cesta

Cliente a actualizar Identificación producto

Identificación cesta para eliminar CLIENTES Top 100 solicitado

Identificación producto a cancelar Identificación pedido

Ventas por cliente

GERENCIA IIC LTDA.

Periodo
Producto Producto
comentado seleccionado

Solicitud de compra Ventas por tipo producto

Categoría a actualizar
Producto a actualizar

SECCIÓN SOLICITUD
Recepción de compra CD a actualizar Producto a describir
A PROVEEDORES

Productos descontinuados Despacho

Libro a actualizar
Palabra

Video a actualizar

Sistema Marraqueta.cl Pedidos

Provisión a actualizar

FINANZAS

Aviso pago
Top 100 CDs

PROVEEDORES

EMPRESAS
Flete a actualizar DE COURIER

Producto cancelado Top 100 libros Descripción avanzada

Pedido cancelado
Mensaje pedido despachado Top 100 videos

Lista productos CLIENTES Descripción producto

Status pedido Detalle pedido

Mensaje pedido solicitado Mensaje pedido en proceso

 128

Periodo
Producto cancelado

Diagrama 0 Solicitud de compra

Inclusiones
Ventas por tipo producto
Identificación cesta
Pedido cancelado
Recepción de compra Mensaje pedido despachado
Identificación pedido
Ventas por cliente 2
Productos descontinuados Pedidos Administrar
pedidos

Mensaje pedido solicitado

Despacho Status pedido
Identificación producto a cancelar
Cliente a actualizar 1
Procesar
pedidos

Detalle pedido

Aviso pago Clientes

Mensaje pedido en proceso

Identificación cesta
Identificación producto cancelado
pasada a caja

Contenidos

Identificación producto

5
Actualizar
4 empresas
Administrar asociadas
Identificación cesta para eliminar cestas
Productos
Fletes
Flete a actualizar
Identificación cesta a nombrar

Provisión a actualizar
Producto comentado

Top 100 solicitado

Lista productos

Top 100 videos

Productos
Top 100 libros Asociados

Palabra
Top 100 CDs
Categoría a actualizar

3 Descripción producto
Producto seleccionado Administrar
productos

Producto a describir

Producto a actualizar

Descripción avanzada
CD a actualizar

Libro a actualizar Video a actualizar

 129

DIAGRAMA 1 - Procesar pedidos

Identificación cesta pasada a caja

Fletes
Identificación cesta

Contenidos

Clientes
eventuales Mensaje pedido despachado

Detalle pedido
1.2 Despacho
1.1 Despachar
Pasar a caja Clientes pedidos
registrados
Mensaje pedido solicitado
Aviso pago
Productos descontinuados

Clientes
permanentes

Pedidos

Productos Lista de despachos

1.6
Revisar stock
Inclusiones Reposición de stock
Clientes
Cliente a actualizar 1.7
Emitir
1.3 solicitud de
Actualizar compra
clientes Solicitud de compra

Mensaje pedido en proceso

Proveedores
1.8 1.4
Verificar Verificar
disponibilidad recepción de Pedido en proceso
stock 1.5
Identificación producto sin stock Actualizar
stock

Identificación producto cancelado

Recepción de compra
 130

Periodo

DIAGRAMA 2 - Administrar pedidos

Ventas por cliente 2.1

Generar
volúmenes de
ventas por
Clientes
cliente

Productos
Productos
asociados

2.2
Actualizar 2.3
productos Generar
asociados volumen de
ventas por
tipo producto

Pedidos
Inclusiones Ventas por tipo producto

2.4 2.5
Consultar Actualizar
pedido rankings

Identificación pedido

Pedido cancelado Identificación producto a cancelar

2.6
Status pedido
Cancelar
producto

Producto cancelado
Identificación producto cancelado
 131

DIAGRAMA 3 - Administrar productos

Categoría a actualizar

Descripción producto

3.1
Actualizar
categorías
Categorías
Producto seleccionado

3.2
Describir
producto

Producto a actualizar

Palabra Libros

CD a actualizar

3.3
Buscar
producto

Lista productos CD's

3.4
Top 100 solicitado Actualizar
productos
Video a actualizar

Videos
Top 100 CDs
Libro a actualizar
3.5
Consultar
top 100

Top 100 libros

3.7
Describir
Productos
más del
producto
Top 100 videos

3.6
Productos
Agregar
asociados
comentarios
Descripción avanzada
Producto comentado

Producto a describir
 132

DIAGRAMA 4 - Administrar cestas

Contenidos
Identificación cesta para eliminar
Identificación producto

Identificación cesta pasada a caja

4.2
4.1 Eliminar
Agregar cesta
producto a
cesta
Productos

Cestas Identificación cesta a nombrar

Clientes
4.3
Asignar
nombre a
cesta
 133

Especificaciones de proceso:
1.1 Pasar a caja

Cantidad total es término local

LEER identificación cesta
SI existe al menos un producto en CONTENIDOS asociado a cesta con id cesta y con disponibili-
dad distinta de discontinuada en PRODUCTOS ENTONCES
ACCESAR id cliente, nombre cliente, dirección personal, dirección de despacho o de
regalo, forma de pago de CLIENTES, CLIENTES REGISTRADOS, CLIENTES
EVENTUALES o CLIENTES PERMANENTES a través de pertenencias con id cesta
ASIGNAR número pedido
AGREGAR id cliente, nombre cliente, dirección personal, dirección de despacho o de
regalo, forma de pago, número pedido, tipo despacho a detalle pedido
AGREGAR pedido a PEDIDOS con número pedido, fecha, tipo de despacho
ASIGNAR 0 a cantidad total, total productos
PARA cada producto en CONTENIDOS de cesta con id cesta
ACCESAR disponibilidad, título de PRODUCTOS con código producto
SI disponibilidad = discontinuada ENTONCES
AGREGAR código producto, título, descontinuación a productos descon-
tinuados
SINO
AGREGAR cantidad como cantidad en estado con estado producto como
solicitado, en INCLUSIONES de pedido con número pedido
INCREMENTAR cantidad total en cantidad
ACCESAR precio, título en PRODUCTOS con código producto
CALCULAR subtotal = precio * cantidad
INCREMENTAR total productos en subtotal
AGREGAR código producto, título, precio, cantidad, subtotal a detalle
pedido
FIN-SI
FIN-PARA
ACCESAR cargo fijo, cargo variable en FLETES con tipo flete
CALCULAR valor tipo flete = cargo fijo + cargo variable * cantidad total
CALCULAR total pago = total productos + valor tipo flete
AGREGAR total productos, valor tipo flete, total pago a detalle pedido
EMITIR detalle pedido
EMITIR id cesta como identificación cesta pasada a caja
SI cliente tiene correo electrónico ENTONCES
AGREGAR correo electrónico, detalle pedido a mensaje pedido en proceso
EMITIR mensaje pedido en proceso vía correo electrónico
FIN-SI
AGREGAR estado producto = solicitado, cantidad en estado (con estado producto = solicita-
do) y cantidad producto ambos como cantidad en INCLUSIONES de número pedido
SINO
PARA cada producto en CONTENIDOS de cesta con id cesta
ACCESAR título en PRODUCTOS con código producto a través de CONTENIDOS
AGREGAR código producto, título, descontinuación a productos descontinua-
dos
FIN-PARA
FIN-SI
SI existe al menos un producto en productos descontinuados ENTONCES
EMITIR productos descontinuados
FIN-SI
 134

1.2 Despachar pedidos

Cantidad total, Cantidad a despachar son términos locales
LEER lista de despachos
PARA cada número pedido en lista de despachos
SI (tipo despacho = total en PEDIDOS con número pedido y no existe producto con esta-
do producto = en tránsito en INCLUSIONES con número pedido) o (tipo despacho = dis-
ponibilidad en PEDIDOS con número pedido) ENTONCES
ACCESAR id cliente, nombre cliente, dirección personal, dirección de despacho
o de regalo de CLIENTES, CLIENTES REGISTRADOS, CLIENTES EVENTUALES o
CLIENTES PERMANENTES a través de solicitudes con número pedido
AGREGAR id cliente, nombre cliente, dirección personal, dirección de despacho
o de regalo, número pedido, tipo despacho a despacho
ASIGNAR 0 a total productos, cantidad total
PARA cada producto con estado producto = en stock en INCLUSIONES
ASIGNAR cantidad en estado (con estado producto = en stock) a canti-
dad a despachar
INCREMENTAR cantidad total en cantidad a despachar
INCREMENTAR cantidad en estado (con estado producto = despachado)
en cantidad a despachar en INCLUSIONES
ASIGNAR 0 a cantidad en estado (con estado producto = en stock) en
INCLUSIONES
ACCESAR precio, título en PRODUCTOS con código producto
CALCULAR subtotal como precio * cantidad a despachar
INCREMENTAR total productos en subtotal
AGREGAR código producto, título, precio, cantidad a despachar como
cantidad, subtotal a despacho
FIN – PARA
ACCESAR cargo fijo, cargo variable en FLETES con tipo flete
CALCULAR valor tipo flete como cargo fijo + cargo variable * cantidad total
CALCULAR total pago = total productos + valor tipo flete
AGREGAR total productos, valor tipo flete, total pago a despacho
AGREGAR número pedido, total pago como monto y fecha a aviso pago
EMITIR aviso pago, despacho
SI cliente tiene correo electrónico ENTONCES
AGREGAR correo electrónico, despacho a mensaje pedido despachado
EMITIR mensaje pedido despachado vía correo electrónico
FIN-SI
SI cantidad en estado (con estado producto = en tránsito) = 0 PARA todos los
productos del pedido en INCLUSIONES ENTONCES
ASIGNAR cerrado a estado pedido, fecha actual a fecha cierre en
PEDIDOS
SI cliente es eventual ENTONCES
ASOCIAR pedido a cliente con id cliente como anónimo en
CLIENTES REGISTRADOS
ELIMINAR cliente eventual de CLIENTES EVENTUALES, cliente
individualizado de CLIENTES REGISTRADOS, cliente de
CLIENTES con id cliente
FIN-SI
FIN-SI
FIN-SI
FIN-PARA
 135

1.3 Actualizar clientes

PRE-CONDICIÓN 1
Se RECIBE cliente modificado.

POST-CONDICIÓN 1
Se ACTUALIZA CLIENTES, CLIENTES REGISTRADOS y CLIENTES PERMANENTES de acuerdo a
cliente modificado.

PRE-CONDICIÓN 2
Se RECIBE cliente nuevo.

POST-CONDICIÓN 2
Se ACTUALIZA CLIENTES, CLIENTES REGISTRADOS y CLIENTES PERMANENTES de acuerdo a
cliente nuevo.

1.4 Verificar recepción de stock

LEER pedido en proceso
PARA cada producto en INCLUSIONES con número pedido con cantidad en estado (con estado
producto = en tránsito) > 0 en INCLUSIONES
SI stock del producto en PRODUCTOS > 0 ENTONCES
SI cantidad en estado (con estado producto = en tránsito) en INCLUSIONES <=
stock del producto en PRODUCTOS ENTONCES
DECREMENTAR stock en cantidad en estado (con estado producto = en
tránsito) en PRODUCTOS
INCREMENTAR cantidad en estado producto (con estado producto = en
stock) en cantidad en estado (con estado producto = en tránsito) en
INCLUSIONES
ASIGNAR 0 a cantidad en estado con estado producto = en tránsito en
INCLUSIONES
SINO
INCREMENTAR cantidad en estado (con estado producto = en stock) en
stock en INCLUSIONES
DECREMENTAR cantidad en estado (con estado producto = en tránsito)
en stock en INCLUSIONES
ASIGNAR 0 a stock en PRODUCTOS
FIN-SI
SINO {stock=0}
ACCESAR disponibilidad en PRODUCTOS con código producto
SI disponibilidad = discontinuada ENTONCES
AGREGAR número pedido, código producto a identificación producto
cancelado
EMITIR identificación producto cancelado
SINO
AGREGAR número pedido, código producto a identificación producto
sin stock
EMITIR identificación producto sin stock
FIN-SI
FIN-SI
FIN-PARA
 136

1.5 Actualizar stock

PRE-
Se recepción de c .

POST-
Se PRODUCTOS INCREMENTANDO en cantidad recibida dis-
de acuerdo a código producto

1.6 Revisar stock

Cantidad a reponer es término local
cada pedido PEDIDOS desde el más antiguo has
HACER CASO
estado pedido solicitado y = Si
PARA cada solicitado INCLUSIONES
cantidad stock del en PRODUCTOS ENTONCES
stock producto en en PRODUCTOS
ASIGNAR tock a , cantidad cantidad en estado a

ASIGNAR en tránsito a , 0 a cantidad en estado

INCLUSIONES
SINO
cantidad stock a a reponer
AGREGAR producto cantidad como cantida solicitada
a r posición de stock
en stock estado producto, a cantidad en estado
INCLUSIONES
en tránsito estado producto, a reponer cantidad
en est do a
ASIGNAR stock del en PRODUCTOS
FIN SI
ASIGNAR a estado producto cantidad en estado a

ASIGNAR cancelado a , 0 a cantidad en estado INCLUSIONES

- PARA
en proceso estado en PEDIDOS
AGREGAR , estado pedido fecha actual mensaje pedido en
proceso
EMITIR mensaje pedido en proceso correo electrónico
cliente correo electrónico
AGREGAR , número pedido estado pedido, a
mens
EMITIR vía correo electrónico
FIN-
CASO estado = en proceso
EMITIR como pedido en proceso
FIN CASO
SI existe con estado producto en stock
AGREGAR número pedido a ista de despachos
– SI
– PARA
existe al menos un producto reposición de stock
 137

EMITIR reposición de stock

FIN – SI
SI existe al menos un pedido en lista de despachos ENTONCES
EMITIR lista de despachos
FIN – SI

1.7 Emitir solicitud de compra

LEER reposición de stock
PARA cada producto en reposición de stock
ACCESAR razón social en PROVEEDORES con RUT a través de PROVISIONES con códi-
go producto
AGREGAR RUT, razón social a solicitud de compra
MIENTRAS haya productos proveídos por el mismo proveedor en reposición de stock
SI existe código producto en solicitud de compra ENTONCES
INCREMENTAR cantidad a comprar en cantidad solicitada en solicitud de
compra
SINO
AGREGAR código producto, cantidad solicitada como cantidad a com-
prar en solicitud de compra
FIN-SI
ELIMINAR código producto, cantidad solicitada de reposición de stock
FIN-MIENTRAS
EMITIR solicitud de compra
FIN-PARA

1.8 Verificar disponibilidad

LEER identificación producto sin stock
ACCESAR fecha en PEDIDOS con número pedido
ACCESAR disponibilidad en PRODUCTOS con código producto
HACER CASO
CASO fecha actual – fecha >= 120 días
SI disponibilidad = desconocida
EMITIR identificación producto sin stock como identificación producto
cancelado
FIN-SI
CASO fecha actual – fecha >= 60 días
HACER CASO
CASO disponibilidad = 1- 2 días
ASIGNAR 7-10 días a disponibilidad en PRODUCTOS con código
producto
CASO disponibilidad = 7- 10 días
ASIGNAR 21-30 días a disponibilidad en PRODUCTOS con código
producto
CASO disponibilidad = 21-30 días
ASIGNAR desconocida a disponibilidad en PRODUCTOS con có-
digo producto
FIN-CASO
EMITIR identificación producto sin stock como identificación producto cancela-
do
FIN-CASO
 138

2.1 Generar volúmenes de ventas por cliente

Valor es término local
LEER periodo
AGREGAR periodo a ventas por cliente
ASIGNAR 0 a total valorado vendido
PARA cada cliente en CLIENTES
ASIGNAR 0 a cantidad vendida CD’s, cantidad valorada CD’s, cantidad vendida libros,
cantidad valorada libros, cantidad vendida videos, cantidad valorada videos
PARA cada pedido en PEDIDOS a través de solicitud con id cliente
ACCESAR fecha cierre en PEDIDOS a través de solicitud con id cliente
SI fecha cierre está entre fecha de inicio y fecha de término ENTONCES
ACCESAR precio en PRODUCTOS con código producto
HACER CASO
CASO tipo producto es CD
INCREMENTAR cantidad vendida CD’s en cantidad en estado
(con estado producto = despachado)
CALCULAR valor = cantidad en estado (con estado producto =
despachado) * precio
INCREMENTAR cantidad valorada CD’s en valor
CASO tipo producto es libro
INCREMENTAR cantidad vendida libros en cantidad en estado
(con estado producto = despachado)
CALCULAR valor = cantidad en estado (con estado producto =
despachado) * precio
INCREMENTAR cantidad valorada libros en valor
CASO tipo producto es video
INCREMENTAR cantidad vendida videos en cantidad en estado
(con estado producto = despachado)
CALCULAR valor = cantidad en estado (con estado producto =
despachado) * precio
INCREMENTAR cantidad valorada videos en valor
FIN-CASO
FIN-SI
FIN-PARA
CALCULAR total valorado vendido por cliente = cantidad valorada CD’s + cantidad valo-
rada libros + cantidad valorada videos
SI total valorado vendido por cliente > 0 ENTONCES
AGREGAR id cliente, cantidad vendida CD’s, cantidad valorada CD’s, cantidad
vendida libros, cantidad valorada libros, cantidad vendida videos, cantidad valo-
rada videos, total valorado vendido por cliente a ventas por cliente
INCREMENTAR total valorado vendido en total valorado vendido por cliente
FIN-SI
FIN-PARA
AGREGAR total valorado vendido a ventas por cliente
EMITIR ventas por cliente

2.2 Actualizar productos asociados

PARA cada pedido en PEDIDOS
PARA cada producto en INCLUSIONES
 139

PARA cada otro producto en INCLUSIONES

SI (código producto, código producto asociado) existe en PRODUCTOS
ASOCIADOS ENTONCES
INCREMENTAR frecuencia en 1 en PRODUCTOS ASOCIADOS
SINO
AGREGAR (producto, otro producto) en PRODUCTOS
ASOCIADOS
ASIGNAR 1 a frecuencia
FIN-SI
FIN-PARA
FIN-PARA
FIN-PARA
ORDENAR en forma descendente PRODUCTOS ASOCIADOS por código producto, frecuencia
PARA cada producto en PRODUCTOS ASOCIADOS
SI existen más de tres asociaciones de un producto
ENTONCES
ELIMINAR la cuarta asociación en adelante en PRODUCTOS ASOCIADOS
FIN-SI
FIN-PARA

2.3 Generar volúmenes de venta por tipo producto

Valor, Lista CD’s, Lista libros, Lista videos son términos locales
LEER periodo
AGREGAR periodo a ventas por tipo producto
ASIGNAR 0 a cantidad total CD’s, cantidad total libros, cantidad total videos, total valorado
CD’s, total valorado libros, total valorado videos
PARA cada producto en PRODUCTOS
ASIGNAR 0 a cantidad vendida en periodo, cantidad valorada en periodo
PARA cada pedido en PEDIDOS a través de inclusión con código producto
ACCESAR fecha cierre en PEDIDOS a través de INCLUSIONES con código pro-
ducto
SI fecha cierre está entre fecha de inicio y fecha de término ENTONCES
INCREMENTAR cantidad vendida en periodo en cantidad en estado (con
estado producto = despachado)
CALCULAR valor = cantidad en estado (con estado producto = despa-
chado) * precio
INCREMENTAR cantidad valorada en periodo en valor
FIN-SI
FIN-PARA
HACER CASO
CASO tipo producto es CD
INCREMENTAR cantidad total CD’s en cantidad vendida en periodo
INCREMENTAR total valorado CD’s en cantidad valorada en periodo
SI cantidad vendida periodo > 0 ENTONCES
AGREGAR código producto, cantidad vendida periodo, cantidad
valorada en periodo a lista CD’s
FIN-SI
CASO tipo producto es libro
INCREMENTAR cantidad total libros en cantidad vendida en periodo
INCREMENTAR total valorado libros en cantidad valorada en periodo
SI cantidad vendida periodo > 0 ENTONCES
AGREGAR código producto, cantidad vendida periodo, cantidad
valorada en periodo a lista libros
 140

FIN-SI
CASO tipo producto es video
INCREMENTAR cantidad total videos en cantidad vendida en periodo
INCREMENTAR total valorado videos en cantidad valorada en periodo
SI cantidad vendida periodo > 0 ENTONCES
AGREGAR código producto, cantidad vendida periodo, cantidad
valorada en periodo a lista videos
FIN-SI
FIN-CASO
FIN-PARA
AGREGAR lista CD’s, cantidad total CD’s, total valorado CD’s, lista libros, cantidad total libros,
total valorado libros, lista videos, cantidad total videos, total valorado videos a ventas por tipo
producto
CALCULAR total valorado vendido = total valorado CD’s + total valorado libros + total valorado
videos
AGREGAR total valorado vendido a ventas por tipo producto
EMITIR ventas por tipo producto

2.4 Consultar pedido

PRE-CONDICIÓN
Se RECIBE identificación pedido.

POST-CONDICIÓN
Se EMITE status pedido con número pedido, estado pedido de PEDIDOS, y el conjunto de produc-
tos con código producto, título y precio de PRODUCTOS, cantidad producto y el conjunto de esta-
dos con cantidad en estado, estado producto de INCLUSIONES.

2.5 Actualizar rankings

Venta CD, venta libro, venta video, posición CD, posición libro, posición video, índice ventas, índice
preferencias son términos locales
PARA cada producto en PRODUCTOS
ASIGNAR 0 a promedio evaluaciones, cantidad vendida
SI existe al menos una cantidad en estado (con estado producto = despachado) > 0
ENTONCES
PARA cada inclusión del producto en INCLUSIONES
INCREMENTAR cantidad vendida en cantidad en estado (con estado pro-
ducto = despachado)
FIN-PARA
FIN-SI
SI existe al menos una evaluación del producto ENTONCES
ASIGNAR promedio de las evaluaciones del producto a promedio evaluaciones
FIN-SI
FIN-PARA
CREAR índice ventas en base a PRODUCTOS ordenados en forma descendente por cantidad
vendida
CREAR índice preferencias en base a PRODUCTOS ordenados en forma descendente por prome-
dio evaluaciones
ASIGNAR 1 a venta CD, venta libro, venta video, posición CD, posición libro, posición video
PARA cada producto en índice ventas e índice preferencias
HACER CASO
 141

CASO tipo producto es CD

ASIGNAR venta CD a posición venta del producto de acuerdo a índice
ventas
ASIGNAR posición CD a posición de preferencia del producto de acuerdo
a índice preferencias
INCREMENTAR venta CD, posición CD en 1
CASO tipo producto es libro
ASIGNAR venta libro a posición venta del producto de acuerdo a índice
ventas
ASIGNAR posición libro a posición de preferencia del producto de acuer-
do a índice preferencias
INCREMENTAR venta libro, posición libro en 1
CASO tipo producto es video
ASIGNAR venta video a posición venta del producto de acuerdo a índice
ventas
ASIGNAR posición video a posición de preferencia del producto de
acuerdo a índice preferencias
INCREMENTAR venta video, posición video en 1
FIN-CASO
FIN-PARA

2.6 Cancelar producto

PRE-CONDICIÓN
Se RECIBE identificación producto a cancelar y cantidad en estado (con estado producto = en
tránsito) > 0 para código producto en INCLUSIONES.

POST-CONDICIÓN
Se ACTUALIZA en INCLUSIONES con estado producto = en tránsito a estado producto = cancelado,
cantidad en estado (con estado producto = cancelado) = cantidad en estado (con estado producto =
en tránsito) y cantidad en estado (con estado producto = en tránsito) = 0 y se EMITE producto cance-
lado a partir de número pedido, código producto, título y cancelamiento productos (SI cliente tiene
correo electrónico, además se EMITE vía correo electrónico). SI no existe producto con estado
producto = (en stock, en tránsito) ENTONCES ACTUALIZAR en PEDIDOS con estado pedido = can-
celado, ASIGNAR fecha actual a fecha cierre y EMITIR pedido cancelado a partir de número pedido,
fecha, fecha cierre y cancelamiento pedido.

3.1 Actualizar categorías

PRE-CONDICIÓN
Se RECIBE categoría a actualizar.

POST-CONDICIÓN
Se ACTUALIZA CATEGORÍAS de acuerdo a categoría a actualizar.

3.2 Describir producto

PRE-CONDICIÓN
Se RECIBE producto seleccionado.

POST-CONDICIÓN
 142

Se EMITE descripción producto a partir de PRODUCTOS, CATEGORÍAS y CD’s o LIBROS o

VIDEOS cuyo código producto coincide con producto seleccionado.

3.3 Buscar producto

PRE-CONDICIÓN
Se RECIBE una palabra no vacía.

POST-CONDICIÓN
Se EMITE lista productos a partir de PRODUCTOS cuyo título, nombre categoría en
CATEGORÍAS, artista o pistas en CD’S, autor o editor en LIBROS, director o actor en VIDEOS
coinciden con palabra.

3.4 Actualizar productos

PRE-CONDICIÓN 1
Se RECIBE producto modificado.

POST-CONDICIÓN 1
Se ACTUALIZA PRODUCTOS de acuerdo a producto modificado y clasificación de acuerdo a
nombre categoría en CATEGORÍAS y CD’s de acuerdo a CD modificado o LIBROS de acuerdo a
libro modificado o VIDEOS de acuerdo a video modificado.

PRE-CONDICIÓN 2
Se RECIBE producto nuevo.

POST-CONDICIÓN 2
Se AGREGA a PRODUCTOS de acuerdo a producto nuevo, con stock = 0 y clasificación de
acuerdo a nombre categoría en CATEGORÍAS y CD’s de acuerdo a CD nuevo o LIBROS de acuer-
do a libro nuevo o VIDEOS de acuerdo a video nuevo.

3.5 Consultar Top 100

PRE-CONDICIÓN
Se RECIBE top 100 solicitado.

POST-CONDICIÓN
Se EMITE top 100 CD’s, top 100 libros o top 100 videos de acuerdo a top 100 solicitado en
PRODUCTOS ordenado en forma descendente.

3.6 Agregar comentarios

PRE-CONDICIÓN
Se RECIBE producto comentado.

POST-CONDICIÓN
Se ACTUALIZA PRODUCTOS de acuerdo a producto comentado.
 143

3.7 Describir más del producto

PRE-CONDICIÓN
Se RECIBE producto a describir.

POST-CONDICIÓN
Se EMITE descripción avanzada a partir de PRODUCTOS y PRODUCTOS ASOCIADOS y CD’s o
LIBROS o VIDEOS cuyo código producto coincide con producto a describir.

4.1 Agregar producto a cesta

CONDICIONES 1 2 3 4 5 6 7 8 9
Dato que acompaña a códi-
go producto ninguno id cliente id cesta id cesta id cliente id cliente id cesta id cliente id cesta
Situación de la cesta ninguno activa activa no activa inexistente activa activa no activa no activa
existe pro- existe pro- existe pro- existe pro- no existe no existe no existe no existe
En depósito CONTENIDOS ninguno ducto ducto ducto ducto producto producto producto producto

ACCIONES
AGREGAR cesta sin nom-
bre cesta en CESTAS ü ü ü
ASIGNAR estado cesta
como activa en CESTAS ü ü ü ü ü
AGREGAR asociación de
producto con cesta a
CONTENIDOS ü ü ü ü ü ü
ASIGNAR cantidad = 1 en
CONTENIDOS ü ü ü ü ü ü
INCREMENTAR cantidad
en 1 en CONTENIDOS ü ü ü
AGREGAR cliente no indi-
vidualizado en CLIENTES ü
ASIGNAR estado cesta
como no activa a cestas
restantes en CESTAS aso-
ciados al cliente a través de
pertenencias ü ü

4.2 Eliminar cesta

PRE-CONDICIÓN
Se RECIBE identificación cesta para eliminar o identificación cesta pasada a caja.

POST-CONDICIÓN
Se ELIMINA contenido de CONTENIDOS asociado por id cesta y cesta con id cesta de CESTAS.

4.3 Asignar nombre a cesta

PRE-CONDICIÓN
Se RECIBE identificación cesta a nombrar, con nombre cesta diferente a todos los nombres ces-
tas de las cestas del mismo cliente, al que pertenece la cesta con id cesta.

POST-CONDICIÓN
Se ACTUALIZA nombre cesta en CESTAS con id cesta.
 144

5.1 Actualizar provisión

PRE-CONDICIÓN 1
Se RECIBE provisión modificada.

POST-CONDICIÓN 1
Se ACTUALIZA EMPRESAS de acuerdo a provisión modificada y provisiones de acuerdo a códi-
go producto.

PRE-CONDICIÓN 2
Se RECIBE provisión nueva.

POST-CONDICIÓN 2
Se ACTUALIZA EMPRESAS de acuerdo a provisión nueva y provisiones de acuerdo a código
producto.

5.2 Actualizar fletes

PRE-CONDICIÓN 1
Se RECIBE flete modificado.

POST-CONDICIÓN 1
Se ACTUALIZA FLETES y EMPRESAS de acuerdo a flete modificado.

PRE-CONDICIÓN 2
Se RECIBE flete nuevo.

POST-CONDICIÓN 2
Se ACTUALIZA FLETES y EMPRESAS de acuerdo a flete nuevo.
 145

Bibliografía

[Bustos&Jaar99] Bustos, Guillermo & Jaar, Paula. Profesores. Problema resuelto

del Sistema de Ventas On-Line www.marraqueta.cl. Asignatura de Sistemas de
Información del Segundo Semestre de 1999, Escuela de Ingeniería Industrial de la
UCV.

[Conallen00] Conallen, Jim. Building Web Applications with UML. 4ta Edición, USA:
Addison-Wesley, Junio 2000.

[Cooley99] Cooley, R., Mobasher, B., and Srivastava, J. Data preparation for min-
ing World Wide Web browsing patterns. Knowledge and Information Systems,
1(1), 1999. Disponible vía web en http://citeseer.nj.nec.com/

[Cooley00] Cooley, R. Web Usage Mining: Discovery and Application of Interest-

ing Patterns from web data. PhD thesis, Dept. of Computer Science, University of
Minnesota, May 2000.

[Deboni99] Deboni, José Eduardo. Modelando a Web com a UML. Objetos Distri-
buídos OD’99. Centro de Convenições Rebouças. Sao Paulo, Brasil, Diciembre 1999.
Diapositivas.

[deChampeaux94] de Champeaux, Dennis. Object-Oriented System Development.

USA: Addison-Wesley, 1994.

[Fellenstein&Wood00] Fellenstein, Craig & Wood, Ron. Exploring E-commerce,

Global E-business, and E-societies. USA: Prentice Hall, 2000.

[González00] González Campos, Fabián. La aplicación de Internet a estrategias

CRM (eCRM). Octubre, 2000. Disponible vía web en http://www.canalti.com

[Güell00] Güell, Natacha; Schwabe, Daniel & Vilain, Patricia. Modeling Interactions
and Navigation in Web Applications. ER 2000 Workshops on Conceptual Modeling
Approaches for E-Business and The World Wide Web and Conceptual Modeling. Salt
Lake City, UTA, USA, October 2000. Editorial Springer-Verlag Berlin Heidelberg
2000, Alemania.

[Heuser01] Heuser, Carlos. Projeto de Banco de Dados. Instituto de Informática da

UFRGS. 4ª Ed. Editora Sagra Luzzatto. Brasil, 2001.

[Høydalsvik&Sindre93] H øydalsvik, Geir & Sindre, Guttorm. On the Purpose of Ob-

ject-Oriented Analysis. ACM SIGPLAN Notices, New York, v.28, n.10, Octubre 1993.
 146

[Jaar&Prieto98] Jaar, Paula & Prieto, Rodolfo. Data Warehouse, Data Marts y Data
Mining. Segunda Monografía de la Asignatura Seminario Tecnologías de la Informa-
ción, Segundo Semestre de 1998, Escuela de Ingeniería Industrial de la UCV.

[Kalakota&Robinson00] Kalakota, Ravi & Robinson, Marcia. e-Business. Roadmap

for succes. 8va Edición, USA: Addison-Wesley, Marzo 2000.

[Manzano00] Manzano, Senior Manager de Ernst Young Consulting. Ernst & Young.
Entrevista publicada en Infoweek. Santiago, Mayo, 2000.

[Pressman98] Pressman, Robert. Ingeniería del Software: Un enfoque práctico. 4ta

Edición, España: McGraw Hill / Interamericana de España, 1998.

[Rossi96] ROSSI, Gustavo Hector. Um Método Orientado a Objetos para o Projeto

de Aplicações Hipermídia. Río de Janeiro: DI / PUC-RIO (Tese de Doutorado).
1996.

[Rossi00] Rossi, Gustavo; Schwabe, Daniel & Lyardet, Fernando. Abstraction an

Reuse Mechanisms in Web Application Models. ER 2000 Workshops on Concep-
tual Modeling Approaches for E-Business and The World Wide Web and Conceptual
Modeling. Salt Lake City, UTA, USA, October 2000. Editorial Springer-Verlag Berlin
Heidelberg 2000, Alemania. Disponible vía web en http://www.telemidia.puc-
rio.br/oohdm/oohdm.html.

[Schwabe&Vilain99], Schwabe, Daniel & Vilain, Patrícia. “Notação da Metodologia

OOHDM”. Río de Janeiro, Abril de 1999. Disponible vía web en
http://sol.info.unlp.edu.ar/notacaoOOHDM.

[Spiliopoulou99] Spiliopoulou, M. Data mining for the web. In Proceedings of Princi-

ples of Data Mining and Knowledge Discovery, Third European conference,
PKDD’99, P588-589. Disponible vía web en http://citeseer.nj.nec.com/

[UML] http://www.rational.com/uml.

[Wang00] Wang, Y. Web Mining and Knowledge Discovery of Usage Patterns. CS

748T Project (Part I). February, 2000.
Disponible vía web en http://citeseer.nj.nec.com/

[Winsberg9?] Winsberg, Paul. Modeling the Data Warehouse and Data Mart. Info
DB, Volume 10, Number 3.

[Zaiane98] Zaiane, O., Xin, M., Han, J. Discovering Web Access Patterns and
Trends by applying OLAP and Data Mining Technology on web Logs. In Advan-
ces in Digital Libraries, pages 19-29, Santa Barbara, CA, 1998. Disponible vía web en
http://citeseer.nj.nec.com/
 147

[Zikmund&d´Amico00] Zikmund, William & d´Amico, Michael. Marketing. Creating

and Keeping Customers in an e-commerce World. 7ma Edición, USA: South-
Western College Publishing, 2000.