maico: documento final - Trabajos de Grado | Ingeniería de Sistemas

MAICO:
DOCUMENTO
FINAL
Javier Alexander Cristancho
Andres Oswaldo Romero
Tabla de contenido
1.
ESTADO DEL ARTE ......................................................................................................... 4
1.1.
Trabajos Relacionados con MAICO ............................................................................. 4
1.2.
Trabajos relacionados con IAM ................................................................................. 5
1.3.
Tablas comparativas .................................................................................................. 7
2.
MAICO........................................................................................................................... 8
2.1.
Descripción ................................................................................................................ 8
2.2.
Componentes ............................................................................................................ 8
2.2.1.
Descripción de los Componentes ........................................................................... 8
2.2.1.1.
Módulo de Componentes Compartidos .............................................................. 9
2.2.1.2.
Descripción del Módulo Empresarial ................................................................ 10
2.2.1.3.
Descripción del Módulo de Comunidad ........................................................... 11
2.2.2.
Representación .................................................................................................... 12
2.2.2.1.
Lenguaje de Representación ............................................................................ 12
2.2.2.2.
Representación del Módulo de Componentes Compartidos ............................. 13
2.2.2.2.1.
Representación del Componente de Información General................................ 13
2.2.2.2.2.
Representación del Componente de Políticas ................................................... 19
2.2.2.2.3.
Representación del Componente Preferencias Sociales .................................... 21
2.2.2.2.4.
Representación del Componente de Interrelación............................................ 25
2.2.2.2.5.
Representación del Componente Institucional ................................................ 26
2.2.2.3.
Representación del Módulo Empresarial .......................................................... 27
2.2.2.3.1.
Representación del Componente de canal ....................................................... 27
2.2.2.3.2.
Representación del Componente de producto ................................................. 28
Representación de almacenamiento ................................................................................... 29
2.2.2.3.3.
Representación del Componente de Logística .................................................. 29
A.
Representación del Componente de Almacenamiento................................................. 29
B.
Representación de transferencia de productos ............................................................ 30
2.2.2.3.4.
Representación del componente de Servicio al Cliente..................................... 31
2.2.2.4.
Representación del Módulo Comunidad........................................................... 33
2.2.2.4.1.
Representación del Componente de Roles ...................................................... 33
2.2.2.4.2.
Representación del Componente de Hábitos ................................................... 35
2.2.2.4.3.
Representación del Componente de Normas .................................................. 36
2.2.3.
2.2.3.1.
Adquisición .......................................................................................................... 38
Mecanismos de Adquisición ............................................................................. 38
2.2.3.2.
Adquisición del Módulo Componentes Compartidos ........................................ 39
2.2.3.2.1.
Adquisición del Componente de Información General ..................................... 39
2.2.3.2.2.
Adquisición del Componente de Políticas ......................................................... 39
2.2.3.2.3.
Representación de Preferencias Sociales .......................................................... 39
2.2.3.2.4.
Representación del Componente de Interrelación............................................ 39
2.2.3.2.5.
Representación del Componente Institucional ................................................ 39
2.2.3.3.
Adquisición del Módulo Empresarial ................................................................ 39
2.2.3.3.1.
Adquisición del Componente Canal .................................................................. 39
2.2.3.3.2.
Adquisición del Componente Producto ............................................................ 39
2.2.3.3.3.
Adquisición del Componente Logística ............................................................. 40
A.
Adquisición del Componente Almacenamiento............................................................ 40
B.
Adquisición del Componente Transferencia de Productos ........................................... 40
2.2.3.3.4.
Adquisición del Componente Servicio al Cliente ............................................... 40
2.2.3.3.5.
Adquisición del Componente de Mercadotecnia y ventas ................................. 40
2.2.3.4.
Adquisición del Módulo Comunidad ................................................................. 40
2.2.3.4.1.
Representación del Componente de Roles ...................................................... 40
2.2.3.4.2.
Representación del Componente de Hábitos ................................................... 40
2.2.3.4.3.
Representación del Componente de Normas .................................................. 41
2.3.
Relaciones ............................................................................................................... 41
2.3.1.
MAICO como Proveedor ...................................................................................... 41
2.3.1.1.
Relación con MOCA .......................................................................................... 41
2.3.1.2.
Relación con MAIPU ......................................................................................... 42
2.3.2.
MAICO como Cliente ............................................................................................ 43
2.3.2.1.
Relación con MOCA .......................................................................................... 44
3.
ROL DENTRO DE IAM ................................................................................................... 45
4.
ESCENARIOS ................................................................................................................ 45
4.1.
Escenario 1 .............................................................................................................. 46
4.1.1.
Escenario 2 .......................................................................................................... 47
4.1.2.
Escenario 3 .......................................................................................................... 49
4.1.3.
Escenario 4 .......................................................................................................... 51
4.1.4.
Escenario 5 .......................................................................................................... 52
5.
CONCLUSIONES Y TRABAJO FUTURO ........................................................................... 54
6.
REFERENCIAS............................................................................................................... 55
1. ESTADO DEL ARTE
En esta sección se presentarán algunos de los trabajos relevantes sobre el modelado de las
comunidades y como estas permiten prestar diferentes servicios a más de un solo usuario. Como se
podrá apreciar a continuación, la mayoría de los modelos se aplica en únicamente un contexto y para un
grupo específico de personas dependiendo de las interpretaciones del concepto de comunidad que
1
cada uno de los autores de en su trabajo . Sin embargo, cada uno de estas interpretaciones servirá de
base para definir un modelo grupal base enriquecido que además de aplicarse en más de un solo
contexto, considere más criterios de clasificación y asociación de usuarios que permitan modelar gran
variedad de comunidades con el fin de prestarles servicios informativos y sugestivos a grupos más
grandes de personas o usuarios.
1.1.
Trabajos Relacionados con MAICO
Kim et al [2] proponen un modelo de aplicación web que provee una mejora a través de internet
denominado PWIMS (Personal Web Information Management System). Este trabajo genera
comunidades agrupando usuarios con las mismas preferencias de búsqueda en la web que
posteriormente son utilizadas para distribuirles a sus integrantes (de acuerdo a sus preferencias
individuales de distribución), información relacionada con la comunidad. A pesar de presentar una
interesante aproximación de modelado web de comunidades, el modelo no considera otros criterios de
clasificación como las preferencias sociales, el comportamiento, y la ubicación geográfica de los
individuos entre otros. Además, descarta la posibilidad de interpretar roles o sub comunidades dentro
de éstas, obviando la posibilidad de ampliar el contexto del modelo por fuera de la web. Atendiendo una
de las falencias de este modelo, Alencar et al [9] propusieron un modelo de capas denominado CIS
(Community Information System) que además de mantener el enfoque de personalización individual y
grupal, considera la aplicación de este modelo por fuera de la web ampliándose al contexto de los
negocios a través de la capa de lógica del negocio que considera la información de consultas, el manejo
de contenido dinámico y de usuarios y la navegación por categorías. Estos aspectos finalmente son
utilizados por la capa superior (la capa de aplicación) quien contextualiza los elementos de la lógica de
negocio a varios dominios y servicios donde se destacan los servicio comunitarios, servicios de compras,
servicios de correo y servicios de chat los cuales pueden ser agrupados para modelar varios contextos de
negocio diferentes.
Al igual que los trabajos descritos anteriormente, existen otras aproximaciones de modelado de
comunidades a través de la web. Pierrakos et al. [3] introduce una nuevo modelo denominado “Web
Community Directories” el cual modela las comunidades utilizando un algoritmo basado en grafos que
identifica patrones de comportamiento a la hora de realizar búsquedas web. Las comunidades
posteriormente son utilizadas para presentarles a sus usuarios información relacionada con sus temas
de interés cuando realicen la búsqueda. A pesar de incluir un nuevo criterio de clasificación de
comunidades, este modelo también carece del uso de otros criterios de clasificación y de la
interpretación de roles o sub comunidades dentro de una comunidad. Atendiendo esta última falencia,
Paliouras et al. [4]propusieron una mejora al modelo descrito anteriormente que consideraba el uso de
las sub comunidades y ampliaba su uso en otros contextos como el empresarial. Otra aproximación
similar fue la propuesta por Jameson, et al. [12] quienes en su modelo de recomendación utilizan las
preferencias sociales de cada uno de los usuarios para clasificar y seleccionar el contenido, los artículos
y la información general que se mostrará al usuario sin considerar otros criterios de clasificación como el
uso patrones de comportamiento.
Además de estas otras aproximaciones web, se encontraron otras tres propuestas de modelado de
comunidades web que toman en cuenta muchos más criterios haciendo las propuestas mucho más
enriquecidas que las anteriores. En primer lugar, Fink et al [10] realizan presentan una investigación de
los modelos de personalización en internet y proponen un modelo que debería tener en cuenta el Perfil
1
Si bien la palabra comunidad deriva de la palabra común y hace referencia a lo que pertenece o se
extiende a varios[1], dicha pertenencia o extensión de varios puede ser desde una simple pertenencia
compartida (como por ejemplo la comunidad femenina, abstracción que se puede hacer al diferenciar
uno de los sexos existentes) hasta una gran variedad de criterios y conceptos comunes entre uno o más
individuos (como las sociedades).
de la compañía, del individuo, del Producto, y los Perfiles de Grupo a través del uso de reglas que
funcionarían como condiciones de activación para asignar un perfil grupal a un usuario individual.
Aunque ésta es una aproximación muy completa del uso de comunidades para generar ingresos (a
través de contextos web y de negocios), dicho enfoque hace que la propuesta no pueda ser aplicada en
más de un contexto y que no considere otros aspectos vitales de una comunidad como los medios de
distribución de la información, la ubicación geográfica y los roles dentro de una comunidad.
Goy et al [11] igual que la propuesta anterior, hacen un análisis del uso de modelos comunitarios en el
contexto de comercio electrónico identificando dos tipos de modelos basándose en el concepto de
2
3
4
adaptación : adaptables , y adaptativos . En estos modelos es importante tener en cuenta el
comportamiento, los temas de interés, las preferencias sociales, los medios de distribución de la
información y los roles dentro de una comunidad para ampliar su utilidad y su uso en más de un solo
contexto.
5
Por último, en Kannan et al. [8] se exploran los roles de los e-communities como intermediarios en el
cambio relacional entre miembros de la comunidad y miembros fuera de ésta. Estas pueden ser
Orientadas a transacciones (compra y ventas), a temas de interés, a fantasías, y a relaciones entre sus
miembros. Para que sean exitosas, deben asegurar contenido de calidad (estandarizado), algunos
niveles de privacidad (dependiendo la comunidad), la presencia de varios individuos dentro de las
mismas que no alteren su funcionamiento o promuevan caos interno.
Además de las propuestas aplicadas en la web, otras propuestas centrarán su trabajo en modelar los
ambientes sociales sin especificar su campo de aplicación. Tal es el caso del trabajo de Baéz-Barranco et
al [5] quieres presentan un modelo basado en sistemas multi-agentes6 que modela todo el
comportamiento social dentro de una comunidad tomando en cuenta las instituciones sociales, los
hechos brutos o eventos dentro de una sociedad, y los eventos institucionales, así como el uso de reglas
distinguidas por constitutivas y regulativas y su priorización, las acciones de los miembros de la
comunidad, y el ambiente en que esta se desarrolla. Sin embargo, esta propuesta además de descartar
la aplicación en negocios, la web u otros contextos, al modelar comportamiento de agentes y no de
individuos, no tomó en cuenta los medios de distribución de la información, los temas de interés de los
agentes y las preferencias sociales.
Por último Stathis et al [7] proponen un modelo futurista aplicado a una sociedad en particular donde
todos los dispositivos tanto públicos como personales interactúan y se adaptan para mantener a la
comunidad conectada. Los componentes propuestos dentro de este modelo son los de interacción,
gente, lugares, eventos, y los factores de conexión (que podrían verse como la meta o fin conjunto de la
comunidad). De la misma manera, el modelo propone el uso y la existencia de conocimiento
compartido dentro de la comunidad así como el uso de agentes de interacción dentro de toda la
comunidad. Sin embargo, el modelo se queda corto en la aplicación en más de un contexto, ya que la
idea sería aplicarlo únicamente dentro de comunidades que no sean virtuales (como por ejemplo en
ciudades) omitiendo la toma en cuenta de otros tipos de comunidades como las comunidades virtuales
y las e-communities.
1.2.
Trabajos relacionados con IAM
Además de servir y ser propuestos como modelos comunitarios, algunos de los trabajos anteriormente
descritos poseen características adicionales que los hacen propuestas que consideran aspectos similares
a los del modelo IAM. Dichas características son: El control de contenido y el uso de perfiles para
2
En el contexto de este trabajo la adaptación hace referencia al proceso o mecanismo seleccionado para cambiar la
información según las preferencias de los usuarios.
3
La adaptación es definida por el usuario
4
La adaptación es establecida por el sistema
5
Las e-communities pueden ser definidas como agregaciones sociales donde se interactúa e intercambia
información con enfocándose en el valor humano y los intereses comunes
6
Los Sistemas Multi Agentes o MAS (por su abreviación en inglés) son definidos como un conjunto de
agentes heterogéneos que están generalmente auto motivados y actual para lograr y cumplir metas
propias o compartir tareas con otros agentes[6].
clasificarlo, la definición de mecanismos y adquisición de la información y la toma en cuenta de los
mecanismos de despliegue.
El modelo propuesto en Kim et al[1] a través de su Agente de monitoreo Web, realiza la adquisición de
la información. Además, incluye un módulo de clasificación de contenido y un agente encargado de
distribuir dicha información a través de ciertos medios de distribución de la información (E-mail, Web
Services, y HTTP). Si bien este modelo ya ha sido aplicado y validado a través de un caso de estudio, este
no toma en cuenta las preferencias individuales y mecanismos de despliegue alternativos diferentes a
los existentes en internet. Estas mismas falencias se encuentran en los modelos propuestos en Pierrakos
et al[3] y Paliouras et al[4] que a través de la personalización con los directorios de comunidades web,
establecen un mecanismo claro de adquisición de la información y administración del contenido para
modelar las comunidades que posteriormente serán utilizadas para trasmitirle información de interés.
Una aproximación bien completa es la propuesta en Stathis et al[7]. Esta proyección futurista además de
identificar las comunidades, modela las preferencias individuales de cada uno de los individuos que la
conforman y como si fuera poco, propone un medio de almacenamiento identificado concreto. Sin
embargo, la carencia de casos de estudio en esta propuesta hace que hoy en día sólo pueda ser vista
como una proyección más no como una realidad en proceso de desarrollo con hechos concretos. Así
mismo, la propuesta de Alencar et al[9] posee casi todas las características de IAM toma (ya que no
establece mecanismos de control sobre el contenido que en este modelo reside) e inclusive, toma en
cuenta otra características interesantes como el establecimiento de comunicación con otras
aplicaciones.
1.3.
Tablas comparativas
Resumiendo los trabajos anteriormente enunciados, la Tabla 1 muestra una comparación entre todos estos trabajos asociados con MAICO y la Tabla 2 muestra una
comparación entre los trabajos y IAM. Para ello se utilizaron una serie de criterios. En cada columna se especifica que criterios considera (+), que criterios no considera (-) y que
criterios no se sabe con certeza si considera (?) cada uno de los trabajos que se describieron anteriormente.
CRITERIO
Consideración del Perfil Individual
Uso de Reglas
Consideración de “Sub Comunidades”
Clasificación por Preferencias Sociales
Clasificación por Comportamiento
Clasificación por Temas de Interés
Clasificación por Lugares y ubicación geográfica
Consideración de medios de distribución
Identificación de Roles dentro de la comunidad
Aplicación en Negocios
Aplicación en la Web
Aplicación en más de un Contexto
CRITERIO
Control de Contenido
Medio de Almacenamiento Identificado
Mecanismos de Adquisición de la Información
Uso de Perfiles para generar y clasificar contenido
Medios de Distribución de la información
identificados
Comunicación con otras aplicaciones establecida
Casos de Estudio documentados o en desarrollo
Kim et
al.[2]
+
+
+
+
+
-
Kim et
al.[2]
+
+
+
+
+
+
Tabla 1: Comparación de los trabajos relacionados con MAICO
Pierrakos Paliouras et Baéz-Barranco
Stathis
Kannan et
et al.[3]
al.[4]
et al.[5]
et al.[7]
al.[8]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
Tabla 2: Comparación de los trabajos relacionados con IAM
Pierrakos Paliouras et
Baéz-Barranco
Stathis
Kannan et
et al.[3]
al.[4]
et al.[5]
et al.[7]
al.[8]
+
+
+
+
+
+
+
+
+/+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
Alencar
et al.[9]
+
+
+
+
+
+
-
Fink et
al.[10]
+
+
+
+
+
+
?
+
-
Goy et
al.[11]
+
+
+
+
+
+
+
+
+
+
Jameson, et
al.[12]
+
+
+
+
-
MAICO
+
+
+
+
+
+
+
+
+
+
+
+
Alencar et
al.[9]
+
+
+
+
Fink et
al.[10]
+
+
+
-
Goy et
al.[11]
+
+
+
-
Jameson,
et al.[12]
+
+
-
IAM
+
+
-
+
+
¿
-
+
+
+
+
2. MAICO
A continuación se realizará una descripción de MAICO que hace parte de la sección del módulo de
contenido de IAM. Esta propuesta pretende modelar comunidades y empresas a través de las
características más significativas y distintivas de estos grupos de individuos. Para ello, el módulo incluye
gran variedad de componentes que además de representar dichas características, establecerán
parámetros de interacción entre ellas, el entorno y los individuos que la conforman
2.1.
Descripción
Figura 1: Arquitectura de MAICO
Como se puede observar en la Figura 1, MAICO se divide en tres módulos Importantes:
Módulo de Componentes Compartidos: Componentes que serán utilizados por los otros dos
componentes del módulo.
Módulo Empresarial: Módulo encargado de modelar el comportamiento y las preferencias de
una empresa. Las preferencias se modelan en relación al desempeño y desarrollo de las
actividades y a los procesos existentes dentro de su empresa.
Módulo de Comunidad: Módulo encargado de modelar el comportamiento y las preferencias
de una comunidad. Una comunidad hace referencia al grupo de personas relacionadas por
algún tema, costumbre, afición, o patrón de comportamiento.
En las secciones siguientes se realizará una descripción detallada de cada uno de estos tres grandes
grupos de componentes existentes en la arquitectura de MAICO, realizando una descripción de alto
nivel de cada uno de ellos e identificando la información que se maneja en cada uno de estos y la
manera en la que será representado dentro del sistema.
2.2.
Componentes
Como se pudo apreciar en la sección anterior, la arquitectura de MAICO se divide en tres grandes
grupos: Componentes Compartidos, Componente Empresarial, Componente de Comunidad. Cada uno
de estos grupos recibe el nombre de componentes ya que cada uno de ellos cumple con un objetivo
específico dentro del módulo e internamente se componen de más partes denominadas
subcomponentes.
A través de esta sección se describirán cada uno de los subcomponentes de la arquitectura de MAICO
mostrados en la Figura 1, partiendo de una descripción general, continuando con la descripción de su
representación y finalizando con la descripción de los mecanismos de adquisición de la información que
cada uno de ellos maneja y sus relaciones con los demás módulos de IAM.
2.2.1. Descripción de los Componentes
En esta sección se realizará la descripción inicial de los componentes que componen MAICO. La
descripción será realizada a través de los Módulos que lo conforman en el siguiente orden: Módulo de
componentes Compartidos, módulo empresarial, módulo comunitario.
2.2.1.1. Módulo de Componentes Compartidos
Figura 2: Componentes Compartidos
Como se puede apreciar en la Figura 2, el módulo de componentes compartidos se compone de un
conjunto de seis componentes que incluyen información relevante y compartida por los otros dos
componentes de MAICO. Aunque estos componentes no generarán por si mismos perfiles comunitarios,
la generación de perfiles en los otros dos componentes dependerá del uso de estos. Además de ello,
estos componentes definirán las pautas de comunicación y jerarquización entre las comunidades.
Componente de Información General: Componente con los datos básicos de un grupo que
facilitan su búsqueda dentro de un directorio de grupos.
Componentes de Políticas: El componente de Políticas modelará las directrices y orientación
que rigen el actuar y las interrelaciones de los grupos. Dicha orientación toma validez cuando
se asocia a una norma o a una interrelación. Algunas de las directrices que se intentarán
modelar con MAICO son:
i. Administración: ¿Quién provee la información o los productos dentro de un grupo?
¿Qué comparte un grupo a los demás? ¿Qué proveen los demás grupos? ¿Qué tipo de
productos o información se maneja dentro del grupo?
ii. Despliegue: ¿Por qué medios se despliegan la información o los productos manejados
dentro de una comunidad?
iii. Seguridad y Privacidad:¿Cómo se garantiza la privacidad de los miembros de la
comunidad?
iv. Interrelación: ¿Quién provee al grupo de información o productos? ¿A que otros grupos
se distribuye productos o se divulga información?
Preferencias Sociales: Módulo que representa las preferencias de la comunidad en torno a las
características sociales de los individuos que la conforman. Entre ellos están la situación
profesional, el estado civil, el credo o religión, niveles de ingresos, origen o nacionalidad que
definirán el perfil de los miembros que la conforman.
Componente Institucional: Este módulo establece las instituciones existentes dentro de un
grupo. Las instituciones son pequeños sub grupos existentes dentro de un grupo.
Componente de Interrelación: Tal y como está descrito en el estado del arte, los autores
Palilouras et al [4], Baéz-Barranco et al [5], Stathis et al [6], y Fink et al[10]consideraron de vital
importancia contemplar dentro de las comunidades la existencia de grupos de interés (o sub
comunidades) y de alianzas o comunicación con otras comunidades e inclusive con ciertas
empresas. Este módulo se encargará de empalmar dichas relaciones y establecer los medios de
comunicación e interacción entre las comunidades.
La Tabla 3 muestra la información que manejará cada uno de los componentes compartidos. La
explicación detallada de cada uno de ellos se irá realizando a lo largo de la sección 2.2.2.2.
Tabla 3: Resumen de Información Manejada por el Módulo de Componentes Compartidos
INFORMACIÓN GENERAL
POLITICAS
PREFERENCIAS
INTERRELACIÓN
INSTITUCIONAL
SOCIALES
Identificador de la
Identificador único de la
Identificador de la
Identificador de la
Grupo Padre
comunidad
política
Preferencia
Interrelación
Grupos Hijo
Nombre de la comunidad
Comunidad dueña de la
Grupo al que
Precursor de la
política
pertenece
interrelación
Tipo de la comunidad
Tipo de la política
Tipo de Preferencia
Grupos
Sectores en los que se
Beneficiados
desenvuelve la
Valores asociados al tipo
Criterios Asociados
7
Comunidad
de la política
al Tipo de
Políticas Asociadas
Preferencia.
Usuarios Miembros de la
Usuario precursor de la
Comunidad
política
Ubicación de la
Comunidad
Líder de la comunidad
2.2.1.2.
Descripción del Módulo Empresarial
Figura 3: Componentes Empresariales
Como se puede apreciar en la Figura 3 el Módulo empresarial costa de 5 componentes. Este módulo
está diseñado por capas donde los dos componentes de la capa baja (Canal y Producto) prestan servicios
a los componentes de la Capa Superior (conformada por el componente de Logística, Mercadotecnia y
Ventas y Servicios). A continuación se realizara una descripción de cada uno de los Componentes que
conforman este módulo:
Componente de Medio de Transporte: Los medios de transporte dentro de una empresa
pueden ser vistos como los medios por los cuales la empresa realiza algunas de sus labores
relacionadas con el desplazamiento de sus productos y materias primas.
Componente de Producto: Los productos son las cosas que producen las empresas y que hacen
parte de todos los procesos de la cadena de valor. Como en este componente se van a modelar
las preferencias que se manejan dentro de una empresa es de vital importancia modelar lo que
en ellas se produce para que a partir de estos se establezcan las preferencias.
Componentes de Logística: Según la cadena de valor descrita por Poter[13] la logística maneja
las actividades relacionadas con la recopilación, almacenamiento y distribución de los insumos
y los productos. Como se puede apreciar en la Figura 4, los componentes de logística son:
i. Preferencias de Transferencias de productos: Dentro de la logística se manejan las
actividades relacionadas con el recibimiento, recopilación, despacho y entrega de
productos e insumos. Las preferencias que cada empresa tengan en esta etapa de la
logística serán modeladas a través de este componente.
ii. Preferencias de Almacenamiento: El almacenamiento modelará las preferencias que
tendrán las empresas con respecto al manejo de inventarios de cada uno de los
productos e insumos que se manejan dentro de ella.
7
Ver el sub numeral A del numeral 0 de la presente sección.
Figura 4. Componentes de Logística
Componente de Mercadotecnia y Ventas: En este componente se modelará las preferencias
que tienen las empresas para publicitar y promover la venta de sus productos.
Componente de Servicio Al Cliente: Parte del valor agregado que le brinda una empresa a sus
productos consiste en el servicio que le prestan a sus clientes al adquirirlo. A través de este
componente se modelarán aquellos servicios que la empresa prefiere prestar para cada uno de
sus productos.
La Tabla 4 muestra la información que manejará cada uno de los componentes compartidos. La
explicación detallada de cada uno de ellos se irá realizando a lo largo de la sección 2.2.2.3.
Tabla 4: Resumen de la Información Manejada por el Módulo Empresarial
PRODUCTO
MERCADOTECNIA Y
SERVICIO
VENTAS
Identificador del Canal
Identificador del
Producto Seleccionado
Id Servicio
producto
para la preferencia
Tipo de Canal
Tipo de Servicio
(Distribución, Venta,
Nombre del producto
Canal de Venta
Almacenamiento)
seleccionado para
Listado de productos
Tipo de Producto
modelar la preferencia
asociados al servicio
Ubicación del Canal
Precio preferido
LOGÍSTICA
CANAL
Preferencias de Recibo
Preferencias de Almacenamiento
Preferencias de Distribución
Productos Asociados a la
preferencia
Producto al que se asocia la
preferencia
Listado de Productos asociado a la
preferencia
Proveedores Seleccionados para
recibir los productos listados
Canal de Almacenamiento al que
se asocia la preferencia
Canales a los que se desea distribuir el
producto
Canales de Distribución
preferidos para recibir los
productos listados
Cantidad en Stock preferida para
ese producto
Canales de Distribución preferidos
trasportar el producto.
Canal de Almacenamiento
preferido para recibir los
productos listados
Periodo de rotación preferido
para ese producto en ese canal
de almacenamiento
Día preferido para recibir los
productos listados
2.2.1.3.
Descripción del Módulo de Comunidad
Figura 5: Componentes Comunitarios
Como se puede ver en la Figura 5 las comunidades serán modeladas con dos componentes. Dichos
componentes son:
Componente de Roles: Los roles dentro de una comunidad son grupos conformados por uno o
más usuarios que tienen asignados el derecho a realizar ciertas actividades que no pueden
realizarse por el resto de los miembros y que en muchas ocasiones sirven como mecanismo de
control y veeduría del comportamiento de todos los miembros de la comunidad. Este
componente modelará dichos sub grupos establecidos dentro de una comunidad, asociando los
usuarios y las actividades a que pertenecen a cada uno de los roles.
Componente de Hábitos: Los hábitos serán vistos en MAICO como una actividad8 que realizan
todos los miembros de la comunidad en un determinado periodo de tiempo.
Componente de Normas: Las normas son vistas por MAICO como las políticas que se deben
seguir y respetar dentro de una comunidad con el fin de preservar la convivencia e interacción
sana entre todos sus miembros junto con los castigos que se aplican al no seguirlas.
La Tabla 5 muestra la información que manejará cada uno de los componentes compartidos. La
explicación detallada de cada uno de ellos se irá realizando a lo largo de la sección 2.2.1.3.
Tabla 5: Información manejada por los componentes del Módulo Comunidad
ROLES
HÁBITOS
NORMAS
Identificador único del
Identificador del hábito
Comunidad dueña de la norma
rol
Comunidad dueña del
Política asociada a la norma
Nombre del rol
hábito
Usuarios que la deben cumplir
Tipo del rol
Tipo del hábito
Usuarios que deben garantizar que
Usuarios asociados al rol
Nombre del hábito
se cumpla
dentro de la comunidad.
Cuando se realiza
Condiciones
Cada cuanto se realiza
Restricciones
Cuanto tiempo dura su
realización
Castigo por Incumplirla
2.2.2. Representación
Ya realizada la descripción de los componentes, se procederá con la representación visual y lógica de
cada uno de ellos. Para la representación visual se utilizarán tablas e ilustraciones (la mayoría de las
ilustraciones serán diagramas jerárquicos que representarán taxonomías y ontologías).
La representación lógica describirá como la representación visual será descrita dentro del sistema. La
representación se hará a través de tuplas cuyo lenguaje será descrito en la sección 2.2.2.1.
2.2.2.1.
Lenguaje de Representación
Para realizar la representación lógica se utilizarán los símbolos descritos en la Tabla 6, mostrando en la
columna izquierda los símbolos que se deben utilizar.
Tabla 6: Lenguaje Utilizado Para la Representación Lógica de Las Tuplas
ELEMENTO A REPRESENTAR
SÍMBOLO
Inicio y fin de una tupla
(c1; c2 ; c3;….;cN)
Donde:
“(“ representa el Inicio de la tupla
“)” representa el final de la tupla
cN representa un elemento simple, compuestos ó
colección de la tupla
Los elementos son separados por “;”
Elemento Simple
Cadena de caracteres con el valor del elemento.
8
La definición detallada de una actividad con su descripción y representación se encuentra en MOCA.
MOCA es el acrónimo de Modelo Contextual de Adaptación y se encuentra documentado en Higuera et
al[16].
Elementos Compuestos: Campos
con más de un valor o
representación. (Utilizados para
representar objetos)
Colección de Elementos
Secuencia
Valor NULO (Valor permitido por
algunos campos)
“,e1,e2,e3…….eN-”
Donde:
“,“ representa el Inicio del elemento compuesto
“-” representa el final del elemento compuesto
eN representa uno de los elementos del elemento
compuesto. Dichos elementos pueden ser:
1. Un elemento simple
2. Otro elemento compuesto
3. Una colección
4. Una secuencia
Los nodos de la colección son separados por “,”
<n1, n2 , n3,….,nN>
Donde:
“<“ representa el Inicio de la colección
“>” representa el final de la colección
nN representa un nodo de la colección. Todos los nodos
deben tener la misma representación. Un nodo puede ser:
1. Un elemento simple
2. Un elemento compuesto
3. Otra colección
Los nodos de la colección son separados por “,”
[s1s2s3…sN+
Donde:
“*“ representa el Inicio de la secuencia
“+” representa el final de la secuencia
sN representa un elemento de la secuencia. Los elementos
de la secuencia pueden ser únicamente simples.
NULL
2.2.2.2. Representación
Compartidos
del
Módulo
de
Componentes
En esta sección se irá mostrando uno a uno la representación lógica de los componentes del módulo de
Componentes Compartidos. Además de la representación lógica, se mostrarán las ontologías
establecidas para cada uno de los componentes pertenecientes al módulo y las taxonomías establecidas
para algunos de sus campos. La representación será descrita en este orden: Información General,
Políticas, Preferencias Sociales, Interrelación, Institucional.
2.2.2.2.1.
Representación del Componente de Información General
Figura 6: Ontología de Información General
Como se puede apreciar en la Figura 6, el componente de información general contendrá los datos
esenciales y primordiales de una comunidad para que pueda ser identificada, y distinguida. A través de
este componente se almacenará la información necesaria para que algún usuario a través de unas
palabras clave, pueda identificar una o un grupo de comunidades afines a sus intereses. Los campos
trabajados en este componente son:
1.
2.
Identificador de la Comunidad(ID COMUNIDAD): Valor único y distintivo entre todas las
comunidades registradas en el sistema, utilizado para diferenciar y reconocer dentro del
sistema a través de un valor, una única comunidad o empresa. Se representará con una C ó una
E (C si es comunidad y E si es empresa) y un entero no repetido.
Nombre: Denominación verbal que los creadores de la comunidad le asignan. Se utilizará un
elemento simple para representarlo.
3.
Tipo: Campo que tiene como objetivo realizar una primera diferenciación entre las
comunidades que describe en qué contexto se desenvuelve la comunidad.
Figura 7: Taxonomía de los Posibles Tipos de Comunidades
La Figura 7 muestra la taxonomía propuesta para utilizar en este trabajo. En primer lugar una comunidad puede
ser “Virtual” o “No Virtual”. Las comunidades virtuales son básicamente aquellas que no estén ubicadas
geográficamente y no posean instalaciones físicas para que sus usuarios interactúen9. A su vez, las comunidades
virtuales se dividen principalmente en10:
Los Foros
Las listas de envío: Estas se dividen a su vez en las comunidades de coreo electrónico y las de
noticias.
Las enfocadas a la comunicación entre sus usuarios (chat). Estas a su vez se dividen en las que
realizan comunicación textual (como por ejemplo el chat clásico) y las que realizan
comunicación virtual (como por ejemplo Haboo Hotel11 . Comunidades con ambientes virtuales
definidos de interacción no solo textual sino visual también)
Las comunidades enfocadas a brindar contenido a sus usuarios con ciertas características.
Por otro lado, se encuentran las comunidades no virtuales. La clasificación clásica de las comunidades no
virtuales distingue dos tipos principales de comunidades: La urbana y la rural. Sin embargo, MAICO
decidió tener en cuenta las comunidades nómadas. Para ello se realizó una división de comunidades
físicas en dos tipos: La nómada y la sedentaria (en esta se colocan la caracterización de tipo de
comunidad por rural y urbana). La representación del tipo de comunidades se realizará especificando
una secuencia con el camino desde la primera diferenciación (virtual ó no virtual) hasta llegar a la
diferenciación más detallada.
Para la representación del campo tipo se utilizarán colecciones donde cada elemento de dicha colección
será una secuencia que especifica un tipo. El Ejemplo 1 muestra dos posibles escenarios de representación. En
la primera representación (A) se está especificando que la comunidad es de tipo “noticias”. La segunda
representación (B) muestra un ejemplo en el que se representan dos tipos (noticias y foros).
A. <[virtuallistas de envíonoticias]>
B. < [virtuallistas de envíonoticias], [virtualforos] >
Ejemplo 1: Representaciones lógicas del Campo Tipo en el Componente de Información General
9
Algunas comunidades virtuales poseen instalaciones físicas administrativas como por ejemplo yahoo.
Sin embargo, no son consideradas comunidades no virtuales ya que sus instalaciones no son utilizadas
por los miembros de la comunidad sino por el personal administrativo de esta.
10
Para mayor información, véase la referencia[14].
11
www.habbohotel.com
4.
Sectores: Según las preferencias, gustos, intereses y características de la comunidad, estas se
desenvuelven en una serie de sectores que hacen una agrupación inicial de los temas sobre los
cuales se desenvuelve la comunidad y sus usuarios. La taxonomía propuesta para modelar los
sectores en este trabajo se encuentra en las ilustraciones mostradas a continuación. La Figura 8
muestra la clasificación taxonómica de primer nivel del campo sector y desde la Figura 9 hasta la
Figura 18 se muestran las subdivisiones establecidas dentro de cada uno de esos primeros niveles.
Figura 8: Taxonomía de Sectores
Figura 9: Taxonomía del Sector de la Informática
Figura 10: Taxonomía del Sector de los Medios
Figura 11: Taxonomía del Sector de Tecnología
Figura 12: Taxonomía del Sector Económico
Figura 13: Taxonomía del Sector Religioso
Figura 14: Taxonomía del Sector Académico
Figura 15: Taxonomía del Sector Ocio
Figura 16: Taxonomía del Sector Gobierno
Figura 17: Taxonomía del Sector Investigación
Figura 18: Taxonomía del Sector Científico
La representación del sector se realizará de la misma forma que la realizada en el campo tipo.
La representación es la misma debido a que se pueden modelar más de un sector dentro de
este campo. El Ejemplo 2 muestra dos casos, en el A una representación de un solo sector, el
ejemplo B muestra como se modelarían más de un sector.
A. <[informáticasoftware]>
B. < [informáticasoftware], [científicosalud] >
Ejemplo 2: Representaciones Lógicas del Campo Sector en el Componente de Información General
5.
Miembros: Colección con los identificadores de los usuarios a los que hace pertenece la
comunidad.
6. Ubicación: A través de este campo, el creador podrá definir y modelar la ubicación de la
comunidad según su contexto. La ubicación varía según el tipo de la comunidad. Si por ejemplo
se trata de una comunidad no-virtual, esta podrá representar la ubicación a través de la
dirección de la instalación física donde se encuentra situada la comunidad. Por el contrario si la
comunidad es virtual, la ubicación podrá estar definida por su dirección IP o por el dominio que
esta posea en la web (dependiendo la representación que se desee hacer). Para facilitar esta
labor, MOCA modelará la ubicación cuyo identificador será referenciado por MAICO. Cuando
MAICO requiera desplegar la información de la ubicación se la solicitará a MOCA. Para más
información véase la sección 2.3.
7. Líder: Referencia al usuario que creó el grupo. Para representar este campo se utilizará el id de
dicho usuario es decir, el correo electrónico.
ID COMUNIDAD
[C||E]+ entero no
repetido
Tabla 7: Resumen de la Representación del Componente de Información General
NOMBRE
TIPO
SECTORES
MIEMBROS
UBICACIÓN
Elemento
Ver Figura 7 y
Ver Figura 8 y
Colección de
Referencia al campo
Simple
Ejemplo 1
Ejemplo 2
correos electrónicos
id del Componente
12
de ubicación
ROL DE LOS LÍDERES
[ID Rol creador de la
comunidad || NULL ]
La Tabla 7 muestra un resumen de la representación del componente de la Información General. La
Tabla 8 muestra un ejemplo tabulado de una representación de una comunidad y el Ejemplo 3 muestra
la representación lógica. Para estos ejemplos se representó el grupo de Proyecto Especial de
Personalización del departamento de Sistemas de la Pontificia Universidad Javeriana.
Tabla 8: Representación de un Grupo de Trabajo de Grado del Proyecto Especial de Personalización Ingeniería de
Sistemas de la Pontificia Universidad Javeriana en el Componente de Información General
ID
NOMBRE
TIPO
SECTORES
C1
Proyecto Especial
<[no virtualasentadaurbana]>
<[académicouniversitario],[investigaciónaplicada],
de Personalización
[informáticaSistemas de Información]>
MIEMBROS
UBICACIÓN
ROL DE LOS LÍDERES
<angela.carrillo@javeriana.edu.co, cristanchoj@javeriana.edu.co, andres1001
Angela.carrillo@javeirana.edu.co
romero@javeriana.edu.co, aragon@javiernana.edu.co, david.marin@javeriana.edu.co,
lnino@javeriana.edu.co>
IG(C1;Grupo de Trabajo de Grado EBA;NULL; <[académicouniversitario],[investigaciónaplicada]>;
<angela.carrillo@javeriana.edu.co, cristanchoj@javeriana.edu.co, andres-romero@javeriana.edu.co,
aragon@javeriana.edu.co, david.marin@javeriana.edu.co, lnino@javeriana.edu.co>;1001;R1)
Ejemplo 3: Representación lógica de un Grupo de Trabajo de Grado del departamento de Ingeniería de Sistemas de la
Pontificia Universidad Javeriana en el Componente de Información General
12
El componente de ubicación hace parte del componente “Espacio/Temporal” de MOCA
2.2.2.2.2.
Representación del Componente de Políticas
Figura 19: Ontología de las Políticas
La Figura 19 muestra los campos que serán utilizados para representar las políticas. Dichos Campos son:
1.
2.
3.
Identificador de las Políticas (ID): Valor único y distintivo entre todas las políticas registradas
en el sistema, utilizado para diferenciar, reconocer, y asociar la política dentro de otros
componentes. Este campo será representado con las siglas “Pol” y un entero único.
Grupo a la que pertenece: Cada una de las políticas que se modelan en MAICO está asociada a
una única comunidad quien es a su vez, la que promueve dicha política. En este campo se
almacenará el ID de la comunidad a quien pertenece dicha política. El Id de las comunidades se
describió en la sección 2.2.2.2.1.
Tipo de Política: Campo que hace una primera diferenciación de las características de la
13
política. Con este campo se podrá definir qué acciones ejecutar con dicha política sobre el
grupo que la modela.
Figura 20: Taxonomía del Tipo de Política
La Figura 20 muestra la caracterización de tipos de política definidos para trabajar en MAICO. Dichos
tipos son:
Internas: Políticas definidas para ser aplicadas dentro del grupo y sus miembros.
Utilizadas primordialmente para definir normas (Ver sección 2.2.2.4.3) y directrices
dentro del grupo que las modela. Las políticas internas se dividen en 4 tipos de
política:
i. Dominio: Política que obligatoriamente deben modelar todos los grupos
registrados en MAICO ya que específica que temas o productos son tratados
dentro del grupo. Los temas o productos asociados a las demás políticas deben
estar registrados en esta política.
ii. Despliegue: Define los medios de despliegue que pueden ser utilizados para
mostrarle la información o los productos a los usuarios de IAM.
iii. Lectura: Política solo para las comunidades que, al asociarse con las normas,
especifican que temas pueden ser vistos o leídos por ciertos roles de la
comunidad.
iv. Escritura: Política solo para las comunidades que, al asociarse con las normas,
determinan que usuarios pueden agregar o modificar información relacionada
con ciertos temas que se manejan dentro de la comunidad.
Externas: Políticas definidas para ser utilizadas para modelar las interrelaciones entre
los diferentes grupos que conforman MAICO. Para este ejercicio, las políticas externas
fueron divididas en:
i.
Divulgación: Política solo para comunidades que establece cuales temas de
un grupo son públicos y pueden ser vistos por otra comunidad.
13
Las acciones que se podrán hacer con las políticas serán de validación. Las políticas se utilizarán para
validar que los usuarios se estén comportando acorde a lo que definido por el grupo tanto a nivel
interno(entre sus usuarios) como a nivel externo(entre los demás grupos relacionados con dicho grupo)
ii.
Distribución: Especifican que productos o temas de información serán
distribuidos a otros grupos.
iii.
Recepción: Especifican que productos o temas de información de fuentes
externas son recibidos y aceptados por el grupo. Cuando una comunidad
establece una interrelación con políticas de Distribución, la comunidad
consumidora debe modelar una interrelación con políticas de recepción que
la validen.
Actividad Asociada: Si el grupo necesita modelar una política que no se ajuste a
ninguno de los dos tipos descritos anteriormente, puede acudir a la representación de
actividades para hacerlo14. En caso de utilizar este mecanismo de representación de
políticas, el grupo deberá escoger este tipo de política. Este tipo de política se divide
en:
i.
Permitida: Implica que la actividad utilizada para representar la política
puede realizarse dentro del grupo.
ii.
Prohibida: Implica que la actividad utilizada para representar no puede
realizarse dentro del grupo.
La representación de este campo se realizará mediante el uso de una única secuencia (ya que
cada política solo puede tener un tipo). El Ejemplo 4 muestra dos posibles representaciones para dos
diferentes tipos de política. La primera representación (A) es para la política de dominio y la segunda (B)
para una política de divulgación.
A. [internasdominio]
B. [externasdivulgación]
Ejemplo 4: Representaciones Lógicas del Campo Tipo de Política del Componente de Políticas
4.
14
Asociaciones: Campo que representa a que productos, medios de despliegue o información se
asocia la política. La asociación es de productos, medios de distribución, o información
dependiendo de la siguientes reglas:
Si la política es de Dominio, Lectura, Escritura, y Divulgación y es modelada por una
comunidad entonces en este campo se representará una colección de temas.
Si la política es de Domino y es modelada por una Empresa entonces en este campo se
representará una colección de identificadores de producto.
Si la política es de Despliegue, Distribución, y Recepción y es modela por una
comunidad en este campo se representará una colección de nombres de medios de
despliegue de la información.
Si la política es de Despliegue, Distribución, y Recepción y es modelada por una
empresa en este campo se representará una colección de identificadores de canales
de distribución modelados en el componente “Canal” del módulo empresarial que se
encuentra descrito en la sección 2.2.2.3.1.
Si la política es de tipo Actividad Asociada (sin importar si es permitida o prohibida), en
este campo se colocará en un elemento simple el nombre de la actividad que fue
modelada para representar la política.
En el Ejemplo 5 se muestra una representación lógica para cada uno de los 4 tipos de
asociaciones enunciados anteriormente: De temas (A), de identificadores de producto15 (B), de
nombres de medios de despliegue de la información(C), de identificadores de canales de
distribución16(D) y de Actividad Asociada (E)
Las Actividades dentro de IAM son representadas por el módulo “Actividad” de MOCA.
La representación del identificador del producto se muestra en la sección ¡Error! No se encuentra el
origen de la referencia..
16
La representación del identificador de canales de distribución se muestra en la sección ¡Error! No se
encuentra el origen de la referencia..
15
A. <video juegos, internet, juegos de mesa>
B. <Pro1,Pro11,Pro11>
C. <email, portal, PDA, movil>
D. <Cd1,Cd2,Cd10>
E. “Fumar”
5.
Representaciones
del Campo
Asociaciones
UsuarioEjemplo
que la 5:emite:
Referencia Lógicas
al usuario
que creó
la política.delEnComponente
este campodesePolíticas
coloca el ID
del usuario (en el caso de IAM el correo electrónico) que creó la política.
ID
Pol+ Entero
único
Tabla 9: Resumen de la Representación del Componente de Políticas
GRUPO A LA QUE PERTENECE
TIPO
ASOCIACIONES
Referencia al Identificador del Grupo al
Ver Figura 20
Ver Ejemplo 5
17
que pertenece la política
y Ejemplo 4
USUARIO QUIEN LA EMITE
Correo electrónico del miembro
creador de la política
La Tabla 9 muestra un resumen de la representación del componente de Políticas. La Tabla 10 muestra
un ejemplo tabulado de una política de dominio y el Ejemplo 6 muestra la representación lógica de
dicho ejemplo. En este caso se representó la política de dominio del grupo de Proyecto Especial de
Personalización que establece que temas son tratados dentro de ese grupo (para este caso son los
temas de personalización, comunidades, dispositivos móviles y contexto).
ID
Pol1
Tabla 10: Representación de la Política de dominio en el Grupo de Proyecto Especial de Personalización
GRUPO A LA QUE PERTENECE
TIPO
ASOCIACIONES
USUARIO QUIEN LA EMITE
C1
[internasdominio]
<personalización, comunidades,
angela.carrillo@javeriana.edu.co
dispositivos móviles, contexto>
POL(Pol1;C1; [internasdominio]; <personalización, comunidades, dispositivos móviles, contexto>;
angela.carrillo@javeriana.edu.co)
Ejemplo 6: Representación lógica de la política de dominio en el Grupo de Proyecto Especial de Personalización para el
Componente de Información General
2.2.2.2.3.
Representación del Componente Preferencias Sociales
Figura 21: Representación del Componente de Preferencias Sociales
Figura 22: Ontología del Componente de Preferencias Sociales
La Figura 21 muestra cómo se van a representar las preferencias sociales en MAICO. Para llevar a cabo
dicha representación, se utilizarán los campos mostrados en la Figura 22. Dichos Campos son:
1. Identificador de las Preferencias Sociales: Valor único y distintivo entre todas las preferencias
sociales registradas en el sistema, utilizado para diferenciarlas y reconocerlas. Este campo será
representado por las siglas Ps y un entero no repetido.
17
El Identificador del grupo se representa en el campo Id del Componente de Información General.
2.
3.
Grupo a la Que Pertenece: Cada una de las preferencias sociales que se modelan en MAICO
está asociada a un único grupo. En este campo se almacenará el ID de la comunidad a quien
pertenece dicha preferencia social. El Id de las comunidades se describió en la sección
2.2.2.2.1.
Tipo de Preferencia: Campo que hace una primera diferenciación de las características de la
preferencia social. Como se mencionó en la sección 2.2.1.1, las preferencias sociales modelan
características sociales que la conforman. Al reconocer el tipo de preferencia MAICO podrá
determinar qué tipo de validaciones debe realizar sobre los criterios para determinar si el
usuario de IAM interesado en ingresar al grupo cumple con las preferencias definidas por dicho
grupo. Cada preferencia tiene asociados ciertos criterios que varían según su tipo.
Figura 23: Taxonomía del Campo Tipo de Preferencia
18
La Figura 23 muestra los tipos de preferencias definidos para utilizar en MAICO . Los 5 tipos de
preferencias definidos son:
i.
Nivel de Ingresos (NI): En una preferencia de este tipo se modelan criterios
relacionados con la capacidad adquisitiva de los miembros que conforman el grupo.
Los criterios asociados a este tipo de preferencia son:
a. Ingreso Mínimo: Criterio que toma en cuenta el mínimo nivel de ingresos que
deben tener los miembros del grupo.
b. Ingreso Máximo: Criterio que toma en cuenta el máximo nivel de ingresos que
deben tener los miembros del grupo.
c. Denominación: Con este criterio se define la moneda y el país con el que se
evalúa el ingreso mínimo y el ingreso máximo. Algunos ejemplos de
denominaciones son: dólares americanos, dólares canadienses, peso
colombiano, peso mexicano.
d. Periodo: Establece el rango de tiempo en el que se mide la preferencia de nivel
de ingresos. Este rango puede ser mensual, bimestral, trimestral, semestral o
anual.
ii.
Nivel de Educación (NE): Este tipo modela la preferencia social relacionada con el nivel
de educación formal19 que poseen los miembros que conforman el grupo. Los criterios
asociados a este tipo de preferencia son:
a. Dominio: Para poder definir un rango de educación mínima o máxima se
necesita conocer que niveles de educación considerados el grupo. MAICO no
definirá un grupo de niveles de educación general ya que este puede variar
entre los grupos. Por eso a través del criterio de dominio los administradores de
la comunidad definen los niveles de educación que serán tenidos en cuenta
dentro de la comunidad.
b. Educación Mínima: Criterio que toma en cuenta el mínimo nivel de estudios
que deben tenar los miembros del grupo.
c. Educación Máxima: Criterio que toma en cuenta el máximo nivel de estudios
que deben tenar los miembros del grupo.
d. Profesiones Permitidas: Si la comunidad desea restringir el ingreso de sus
usuarios según el tipo de profesiones que hayan estudiado sus miembros,
18
Para el ejercicio que se ha venido desarrollando con IAM solo se consideraron esas 4 preferencias
sociales. Sin embargo, MAICO permite que se puedan modelar más preferencias sociales. Para ello
basta con establecer el nombre y los criterios asociados a dicha preferencia.
19
Educación Formal: Tipo de educación que pertenece a un modelo académico y administrativo de una
nación.
iii.
iv.
v.
puede utilizar este criterio para asociar esa restricción a este tipo de
preferencia.
Estado Civil (EC): Puede que el grupo que se esté modelando dentro de MAICO
considere pertinente que sus miembros tengan necesariamente un estado civil
compartido por todos. Si por ejemplo se desea modelar una comunidad de solteros o
divorciados o una empresa donde no se permita que sus empleados estén casados, se
tendría en cuenta este tipo de preferencia para especificar que no se permiten
miembros con el estado civil “Casado”. El criterio asociado a este tipo de preferencia
es Estados Civiles Permitidos donde se le asociará una colección de estados civiles
permitidos dentro del grupo. Los estados civiles utilizados dentro de MAICO son:
Soltero
Casado
Divorciado
Viudo
Unión Libre
Nacionalidades (NA): Al igual que ocurre con el estado civil, algunos grupos prefieren
restringir sus membrecías a usuarios pertenecientes a ciertos países. Si por ejemplo se
desea modelar una comunidad Colombiana de juegos de mesa lo más conveniente es
restringir las membrecías a solo usuarios de nacionalidad Colombiana. Los criterios
definido para modelar este tipo es el de naciones permitidas es el de nacionalidades
permitidas y el de nacionalidades restringidas. Asociado a este criterio irá una
colección con los nombres de los países. El listado de los países utilizado por MAICO es
el mismo que utiliza la Real Academia de la Lengua Española[15].
Ocupación (OC): Este tipo modela la preferencia social dentro del grupo relacionada
con los trabajos, oficios u ocupaciones que ejercen sus miembros. Los criterios
asociados con este tipo de preferencia son:
a. Dominio: En este criterio se definen todas las ocupaciones sobre las que se va a
evaluar la preferencia dentro del grupo.
b. Ocupaciones Permitidas: En este criterio se almacena el listado de ocupaciones
preferidos por el grupo para sus usuarios. Si un usuario quiere pertenecer a un
grupo que modele una preferencia con este criterio, el usuario deberá tener
una ocupación que pertenezca a las listadas en este criterio. Las ocupaciones
permitidas deben estar registradas en el criterio de dominio.
Para representar el tipo de preferencia se colocará la abreviación asociada a cada uno de los
tipos de preferencias que se describieron con anterioridad (Las abreviaciones definidas para
utilizar en MAICO son: NI, NE, NA, EC, y OC).
4. Criterios Asociados: Como se pudo apreciar en el numeral anterior cada tipo de preferencia
social tiene asociados criterios que establecen las características del tipo de preferencias. Para
modelar los criterios se utilizará una colección de elementos compuestos. Cada elemento
compuesto representará un criterio. Los sub campos que componen el campo criterio (que se
muestran en la Tabla 11) son dos: Tipo y Valor. El primero en representarse es el tipo y el
segundo es el valor. Como se puede apreciar en la tabla, la representación del campo valor
varía según el tipo de criterio.
TIPO DE
PREFERENCIA
NI
NE
EC
NA
OC
Tabla 11: Representación del Campo “Criterio” en el Componente de Preferencias Sociales
TIPO DE
VALOR
EJEMPLO
CRITERIO
Ingreso Mínimo
Numérico con dos decimales
{ingreso mínimo, 2800.00}
Ingreso Máximo
Numérico con dos decimales
{ingreso máximo, 18000.00}
Denominación
Secuencia
{denominación,[colombiapeso$]}
[NaciónMonedaSímbolo]
Donde: Nación: Nombre del país. Moneda:
Nombre de la Moneda. Símbolo: Símbolo de
la Moneda
Período
Entero representando el número de meses
{periodo,12}
(1 = un mes, 2=bimestral, 3=
trimestral,6=semestral,12=anual)
Dominio
Secuencia con los Niveles de Educación
{dominio,
definidos por la Comunidad. El primer
[PrimariaBachilleratoUniversitarioPost
campo es el nivel de educación más bajo y
Grado]}
el último es el más alto
Educación
Elemento Simple representando el nivel de
{educación mínima, Bachillerato}
Mínima
educación. Dicho nivel debe estar incluido
en el domino
Educación
Elemento simple representando el nivel de
{educación máxima, Universitario}
Máxima
educación. Dicho nivel debe estar incluido
en el domino
Profesiones
Colección con el nombre de las profesiones
{profesiones permitidas, <ingeniería de
Permitidas
Permitidas dentro del grupo
sistemas, psicología, filosofía>}
Estados Civiles
Colección con los estados civiles permitidos
{estados civiles permitidos,<soltero, viudo,
Permitidos
dentro del grupo
divorciado>}
Nacionalidades
Colección con los nombres de las naciones
{nacionalidades
Permitidas
permitidas
permitidas,<colombia,argentina,peru>}
Nacionalidades
Colección con los nombres de las naciones
{nacionalidades
Restringidas
que no son tomadas en cuenta dentro del
restringidas,<bolivia,venezuela,ecuador>}
grupo.
Dominio
Secuencia con las ocupaciones organizadas
{dominio,[estudiantecargo tecnicocargo
de la ocupación de menor rango a la de
profesionaleducador]}
mayor rango
Ocupaciones
Colección con las ocupaciones. Estas
{ocupaciones permitidas, <estudiante>}
Permitidas
ocupaciones deben estar incluidas en el
dominio.
Para clarificar un poco la representación de este campo se mostrará une ejemplo. El Ejemplo 7
muestra la representación lógica que adquiere este campo para una preferencia social de tipo
NI donde se restringe la membrecía de la comunidad a usuarios con un ingreso anual igual o
superior a los 18000 dólares Estadounidenses (US).
<{ingreso minimo,18000},{denominación,[estados unidos de
americadólarus]},{periodo,12}>
Ejemplo 7: Representación Lógica del Campo Criterios Asociados para una Preferencia Social de Tipo NI
Tabla 12: Resumen de la Representación del Componente de Preferencias Sociales
ID
GRUPO A LA QUE PERTENECE
TIPO DE PREFERENCIA
CRIERIOS ASOCIADOS
Ps+ Entero único
Referencia al Id del grupo al que
Ver Figura 23
Colección de Elementos Compuestos.
pertenece la preferencia social
Ver Tabla 11 y Ejemplo 7
La Tabla 12 muestra un resumen de la representación del componente de Políticas. La Tabla 13 muestra
un ejemplo tabulado de una preferencia social y el Ejemplo 7 muestra la representación lógica de dicho
ejemplo. En este caso se representaron dos preferencias sociales del grupo de Proyecto Especial de
Personalización: A) El nivel de educación mínimo es el universitario y B) Las ocupaciones permitidas para
los miembros de dicho grupo son estudiante de pregrado y profesor de planta.
Tabla 13: Representación de dos Preferencias Sociales del Grupo de Proyecto Especial de Personalización
GRUPO A LA
TIPO DE
CRIERIOS ASOCIADOS
QUE PERTENECE PREFERENCIA
Ps1
C1
NE
<{dominio, [primariabachilleratouniversitariopost
gradodoctorado]},{educación mínima, universitario }>
Ps2
C1
OC
<{dominio,[estudiante pregradoestudiante postgradoprofesor de
cátedraprofesor de planta]},{ocupaciones permitidas,<estudiante
pregrado, profesor de planta>}>
ID
A.
Ps(Ps1;C1;NE;<{dominio, [primariabachilleratouniversitariopost
gradodoctorado]},{educación mínima, universitario }>)}
B. Ps(Ps2;C1;OC;<{dominio,[estudiante pregradoestudiante postgradoprofesor de
cátedraprofesor de planta]},{ocupaciones permitidas,<estudiante pregrado, profesor de planta>}>)
Ejemplo 8: Representación lógica de un Grupo de Trabajo de Grado del departamento de Ingeniería de Sistemas de
la Pontificia Universidad Javeriana en el Componente de Información General
2.2.2.2.4.
Representación del Componente de Interrelación
Figura 24: Representación del Componente de Interrelación
La Figura 24 muestra la forma en que será representado el componente de interrelación. Básicamente,
las interrelaciones ocurren entre dos o más grupos (comunidades o empresas). Para formalizar dicha
interrelación se asocian ciertas políticas que garanticen la calidad de la interrelación. Por esto se
consideró pertinente realizar la representación a través de redes semánticas.
Figura 25: Ontología del Componente Interrelación
Para representar esa red semántica se utilizará la ontología que se muestra en la Figura 25. En dicha
figura también se muestran los campos que se van a utilizar para la representación. Dichos campos son:
1. Identificador de la Interrelación (ID): Valor único y distintivo entre todas las interrelaciones
registrados en el sistema. Utilizado para diferenciar, reconocer, y asociar las interrelaciones
dentro de otros componentes. Este campo será representado con las siglas “Ir” y un entero
único.
2. Precursor: Grupo que promueve la interrelación. Para representar este campo se colocará el
identificador del grupo que la promueve.
3.
4.
Beneficiados: Listado de grupos que se van a ver beneficiados por la interrelación. Para
representar este campo se utilizará una colección con los identificadores de los grupos que se
verán beneficiados por la interrelación.
Políticas Asociadas: Las políticas asociadas definirán las directrices de la interrelación. En el
caso de este trabajo las políticas que se verán involucradas en las interrelaciones serán las de
recibo y distribución. Para representar este campo se utilizará una colección con los
identificadores de las políticas.
ID
Ir+ Entero
único
Tabla 14: Resumen de la Representación del Componente de Interrelación
PRECURSOR
BENEFICIADOS
POLÍTICAS ASOCIADAS
Identificador del grupo (asignado el
Colección de
Colección de Identificadores
Componente de Información General)
Identificadores de Grupos
de Políticas
La Tabla 14 muestra un resumen con los campos del componente de interrelación y la forma en que
cada uno de ellos se representa. Para aclarar un poco la representación supongamos que existe una
comunidad para los estudiantes de proyecto especial de personalización (De id C1) que desea compartir
la información que poseen sobre el tema de comunidades a la comunidad de estudiantes del proyecto
especial de narratopedia (De id C2). La representación sería la que se muestre en el siguiente ejemplo
(Ejemplo 9):
IR(C1; <C2>; <Pol10>)
Donde P10= (Pol10;C1; [externasdistribución]; <comunidades>; angela.carrillo@javeriana.edu.co)
Ejemplo 9: Representación Lógica de la Interrelación entre el Proyecto Especial de Personalización y Narratopedia
(Parte 1)
Como se mencionó en numeral 2.2.2.2.2, la política de distribución no será validada si del lado de los
grupos beneficiados no se genera una interrelación con una política de recepción. Dicha interrelación
quedaría de la siguiente manera (Ejemplo 10):
IR (C2; <C1>; <Pol11>)
Donde Pol11= (Pol11;C2; [externasrecepción]; <comunidades>; luis.diaz@javeriana.edu.co)
Ejemplo 10: Representación Lógica de la Interrelación entre el Proyecto Especial de Personalización y
Narratopedia (Parte 2)
2.2.2.2.5.
Representación del Componente Institucional
Como se mencionó en la sección 2.2.1.1, este componente pretende representar los subgrupos
pertenecientes a un grupo. Para aclarar un poco este concepto se utilizará un ejemplo. Como se puede
apreciar en la Figura 26, la comunidad Bogotá (De identificador C1) se compone a su vez de otros 4
grupos que constan de 3 comunidades (Policía Nacional, Universidad Javeriana, Alcaldía Mayor) y una
empresa (Bogotá Beer Company).
BOGOTÁ (C1)
POLICÍA
NACIONAL (C2)
UNIVERSIDAD
JAVERIANA(C3)
ALCALDÍA
MAYOR (C4)
Figura 26: Algunas instituciones de la Comunidad Bogotá
Bogotá Beer Company
(E1)
Figura 27: Ontología del Componente Institucional
Para poder hacer esta representación se utilizarán los campos que se muestran en la Figura 27. Dichos
campos son:
1. Grupo Padre: Grupo al que las instituciones pertenecen. En el ejemplo el padre sería el grupo
Bogotá. Para representar este campo se utilizará un campo simple donde se colocará el
identificador de un grupo.
2. Grupos Hijos: En este campo se listarán las instituciones del grupo padre. Para representar esto
se utilizará una colección de identificadores de grupos.
Tabla 15: Resumen de la Representación del Componente Institucional
GRUPO PADRE
GRUPOS HIJOS
Identificador del Grupo dueño de
Colección de Identificadores de
las instituciones
Grupos
La Tabla 15 muestra un resumen con los campos del componente institucional y la forma en la que cada
uno de ellos se representa. Utilizando este mecanismo, la representación lógica del ejemplo enunciado
anteriormente sería la siguiente (Ejemplo 11):
IN(C1; <C2,C3,C4>)
Ejemplo 11: Representación Lógica en el Componente Institucional de la abstracción del grupo Bogotá
A lo largo de esta sección se explicó cómo iban a ser representados los componentes que hacen parte
del módulo de componentes compartidos. A continuación se realizará la descripción de la
representación del módulo empresarial y posteriormente el del módulo comunidad. A través de esas
representaciones se reflejará el uso y la aplicación de los componentes anteriormente descritos.
2.2.2.3.
Representación del Módulo Empresarial
En esta sección se irá mostrando uno a uno la representación lógica de los componentes del módulo
Empresarial. Además de la representación lógica, se mostrarán las ontologías establecidas para cada
uno de los componentes pertenecientes al módulo y las taxonomías establecidas para algunos de sus
campos.
2.2.2.3.1.
Representación del Componente de canal
Figura 28. Ontología del componente de canal
Como se puede apreciar en la Figura 28, el componente de canal poseerá los datos importantes para
que pueda ser caracterizada e identificada. Por medio de este componente se almacenara la
información necesaria para que un usuario pueda definir cuáles son sus preferencias de acuerdo al canal
de distribución que desea utilizar, ya sea para actividades de compra de productos, como para la venta
de éstos. A continuación se describirá cada uno de los campos que hacen parte de la representación de
un canal:
1.
ID: valor único entre los distintos canales que están registrados dentro del sistema, y es
utilizado para diferenciarlos y reconocerlo fácilmente de otros a través de un valor. Se
representara con las siglas “CA” (Canal), seguido de un número entero único.
2.
3.
4.
Tipo: Este campo hace la primera diferenciación a las características del canal. Los canales de
distribución se dividen en canales directos (que se refiere a los productores o fabricantes que
venden productos servicios directamente al consumidor sin intermediarios) y en canales
indirectos (el cual se refiere a distribución de productos por medio de intermediarios). La
representación. La representación de este campo, se realiza por medio de un elemento simple
donde los valores permitidos son:
a. “Directo”, el cual se refiere a canales de distribución directa.
b. “Indirecto”, hace referencia a canales de distribución indirecta.
Clasificación: Esta clasificación permite conocer el tipo de distribuidor con el que se establece
una relación comercial, existen clasificaciones entre distribuidores minorista (hace referencia a
las empresas comerciales que venden productos al consumidor final) y mayoristas (el cual hace
referencia a empresa comerciales que venden grandes cantidades de productos y no tienen
contacto directo con el usuario final del producto). La representación de este campo, se
realizara con un elemento simple, donde los valores permitidos son minorista y mayorista.
Medio de distribución: A través de este campo se podrá definir cuál será el medio de
distribución (e.g. barco, avión, camión, virtual) por donde se realizará la transacción comercial
del producto, para que este pueda llegar al cliente. El campo de medios de distribución se
representará por medio de una secuencia de elementos
Figura 29. Taxonomía de los medios de distribución
Como se puede apreciar en la Figura 29, se muestra la clasificación taxonómica de los medios
de distribución, que permiten que los productos puedan ser entregados de distintas formas,
entre estos se identificaron algunos como el fluvial, aéreo, y el terrestre que hace referencia al
transporte de productos físicos. Otro medio que se identificó fue el virtual, que como su
nombre lo indica, hace referencia a la entrega de productos que son completamente digitales,
como programas, software, imágenes digitales, entre otros, que pueden ser distribuidos por
estos medios.
Tabla 16. Resumen de la representación de los canales
ID
TIPO
CLASIFICACIÓN
MEDIO DE DISTRIBUCIÓN
Ca + Valor entero no
Elemento Simple
Elemento simpe
Secuencia de elementos
repetido
La Tabla 16 muestra un resumen de los campos del componente de canal y la forma en que cada uno de
ellos se representará. La Tabla 17 muestra un ejemplo tabulado de un canal de distribución y el Ejemplo
12 muestra la representación lógica de dicho ejemplo. En este caso se represento un canal de
distribución enfocado a la entrega de archivos que pueden ser descargados desde internet, donde se
define que la descarga se realizara directamente, así mismo, que serán pocos los elementos que se
descargarán.
Tabla 17. Representación de un canal para descarga de archivos de manera directa.
ID
TIPO
CLASIFICACIÓN
MEDIO DE DISTRIBUCIÓN
CA1
Directo
Minorista
[VirtualDescarga]
CA(Ca1;Directo; Minorita;[VirtualDescarga])
Ejemplo 12. Representación lógica de un canal de distribución, donde se realiza descarga de archivos de manera directa
2.2.2.3.2.
Representación del Componente de producto
Figura 30. Ontología del componente de producto
La Figura 30 muestra el componente del producto, el cual poseerá la información necesaria para
modelar las características básicas de un producto. Por medio de este componente se almacenara la
información necesaria para que un usuario pueda definir cuáles son sus preferencias de acuerdo a los
productos que ofrece y de los que se provee. A continuación se describirá cada uno de los campos que
hacen parte de la representación del producto:
1.
ID: valor único entre los distintos productos que puede almacenar y qe se pueden registran en
el sistema de inventarios de una empresa, este valor único será utilizado para diferenciar los
productos fácilmente. Se representara con las siglas “PROD” (Producto) junto con un número
entero único.
2. Nombre: este campo representa el nombre del producto que se tiene en el mercado. Es
utilizado como descripción básica del producto. Así como el número de identificación, le
permitiría reconocer el producto, ofreciéndole al usuario obtener datos adicionales acerca del
producto que permita caracterizarlo. Para representar de este elemento se utilizara un
elemento simple.
3. Marca: este campo permite caracterizar el emblema o nombre del distribuidor del producto,
con el objetivo de diferenciar los productos que tengan la misma funcionalidad, pero que son
elaboradas y posiblemente distribuidas por distintas compañías. Para la representación de este
elemento se utilizará un elemento simple que contenga la marca del producto.
4. Precio: este campo representa el valor comercial del producto que se está modelando, este
campo se representara con un elemento compuesto que poseerá el valor comercial de este
producto en el mercado y la métrica del valor. Sin importar, si se modelan las preferencias de
comprador o vendedor, permitirá caracterizar dichas preferencias con el objetivo de conocer
más a los clientes y a los proveedores.
Tabla 18. Resumen de las representación del componente producto
ID
NOMBRE
MARCA
VALOR
PROD + valor entero único
Elemento Simple
Elemento Simple
Elemento compuesto,
primer campo valor,
segundo métrica.
En la Tabla 18 se resumieron los campos que representan el componente de producto. Estos campos
serán necesarios para realizar una correcta diferenciación del producto. Seguidamente, se realizaron
ejemplos en la representación del campo de producto. En la Tabla 19 se muestra los campos del
componente producto enfocado a un ejemplo específico, posteriormente, en el Ejemplo 13 se muestra
la representación lógica de dicho ejemplo.
ID
PROD1
Tabla 19. Representación de un producto, aplicado a la información anterior
NOMBRE
MARCA
VALOR
Detergente
Ariel
{2.000, Pesos
colombianos}
PROD(PROD1;Detergente;Ariel;{2000,Pesos colombianos})
Ejemplo 13. Representación lógica de los campos que se tienen en cuenta para modelos un producto
Representación de almacenamiento
2.2.2.3.3.
Representación del Componente de Logística
Como se puedo apreciar en la sección 2.2.1.2, el componente de logística se divide en dos grandes
subcomponentes: El de almacenamiento y el de Transferencia de Productos los cuales serpan descritos a
continuación.
A.
Representación del Componente de Almacenamiento
Figura 31. Ontología del componente de almacenamiento.
La Figura 31 muestra el componente de almacenamiento; este posee información necesaria para
modelar las características básicas del almacenamiento de productos. Por medio de este componente se
pretende caracterizar el proceso de almacenamiento de productos dentro de una empresa, con el
objetivo de que la empresa pueda modificar las preferencias de almacenamiento de sus productos. A
continuación se describirá cada uno de los campos que hacen parte de la representación del producto:
1.
2.
3.
4.
5.
ID: valor único que permite reconocer en el sistema de una empresa, los posibles formas de
almacenar los productos, este valor único será utilizado para diferenciar las formas de
almacenamiento con mayor facilidad. Se representara con las siglas “ALM” (almacenamiento)
junto con un número entero único.
Cantidad de productos: este campo representa la capacidad máximo de productos permitidos
durante el proceso de almacenamiento de los productos, este valor será representado con un
elemento compuesto de dos campos, una campo representa la cantidad y el otro la métrica.
Productos compatibles: este campo permite representar los productos que podrán ser
almacenados, y si se almacena más de un clase de producto, agrupar los que son compatibles
durante el almacenamiento. Para la representación de este elemento se utilizará una colección
de elementos que contenga la “IDs” de los productos que serán almacenados (Ver Sección
2.2.2.3.2).
Productos no compatibles: con el objetivo de diferenciar los productos que pueda no ser
compatibles durante el almacenamiento (e.g. un alimento refrigerado, junto con un
detergente), este campo representara de una colección de elementos que contenga los “IDs”
de los productos que no son compatibles durante el almacenamiento (Ver Sección 2.2.2.3.2).
Políticas asociadas: este campo representa las políticas de almacenamiento elaboradas por una
empresa. Este campo será representado con una colección de IDs de políticas asociadas. (ver
sección 2.2.2.2.2).
Tabla 20. Resumen de la representación del componente de almacenamiento
ID
Alm
valor
entero
único
CAPACIDAD MÁXIMA
+
Colección
elementos,
cantidad,
métrica.
de
dos
primero
segundo
PRODUCTOS
COMPATIBLES
Colección de id
de productos
PRODUCTOS NO
COMPATIBLES
Colección de Id de
productos no compatibles
durante
el
almacenamiento.
POLÍTICA ASOCIADA
Colección de Ids de
políticas asociadas al
almacenamiento
(ver
sección 2.2.2.2.2)
En la Tabla 20 se resumen la representación de los campos de almacenamiento. La Tabla 21 hace
alusión a un ejemplo tabulado de almacenamiento, y el Ejemplo 14 muestra la representación lógica de
dicho ejemplo. En este caso se represento el almacenamiento de tres productos compatibles en el
almacenamiento, la capacidad máxima de almacenamiento es de 10.000 kilos y existen tres productos
que no son compatibles con este almacenamiento. Así mismo este almacenamiento será pautado bajo
ciertas políticas.
Tabla 21. Representación de un ejemplo del componente de almacenamiento de tres productos, junto
con una política de almacenamiento
ID
CAPACIDAD MÁXIMA
Alm1
{10.000,kilos}
PRODUCTOS
COMPATIBLES
<Prod1,Prod2,Prod20>
PRODUCTOS NO
COMPATIBLES
<Prod5,Prod7,Prod8>
POLÍTICA ASOCIADA
<Pol25,Pol31>
ALM(Alm1;{10.000,kilos};<Prod1,Prod2,Prod20>;<Prod5,Prod7,Prod8>;<Pol25,Pol31>)
Ejemplo 14. Representación lógica del ejemplo del componente de almacenamiento, asociado a tres productos
B.
Representación de transferencia de productos
Figura 32. Ontología del componente de transferencia de productos.
En la Figura 32 se muestra los campos que representan el componente de transferencia de productos,
este componente tienen como objetivo principal, caracterizar las actividades de compra y venta de
productos dentro de una empresa, dicha transferencias se puede ser realizada por más de dos partes.
Así mismo, se busca definir la recepción de productos a una compañía y la distribución de los productos
que la empresa comercia. A continuación se describirán cada uno de los campos que hacen parte del
componente de transferencia de productos.
1. Id transferencia: este campo representa un valor único y distintivo, que permite reconocer una
transferencia de productos que esté registrada en el sistema. Para representar este campo se
utilizarán las siglas “TRAN” y un valor entero único.
2. Id Interrelación: este campo representa la interrelación que ocurre entre dos o más empresas,
definidas en el componente compartido de interrelación, donde también se definen las
políticas asociadas a esta interrelación. Para la representación de este campo se utilizara el Id
del componente de Interrelación (ver sección 2.2.2.2.4).
3. Id Canal: define el canal por donde se realizar la transferencia de los productos. Para la
representación de este campo se utilizara el ID del canal utilizado.
4. Fecha: Define el día exacto en que se realizar la transferencia. La representación de este campo
es tomada del campo “Hora” del componente Espacio/Temporal de MOCA.
5. Hora: Define la hora exacta en la que se realizar la transferencia de productos. La
representación de este campo es tomada del campo “Hora” del componente Espacio/Temporal
de MOCA.
6. Duración: Algunos transferencias pueden establecer un lapso de tiempo en el cual se desarrolla
la transferencia de productos. La representación de este campo es tomada del campo
“Duración” del componente de Actividad de MOCA.
7. Periodicidad: La transferencia de productos puede ser una actividad que se repita tras un
periodo de tiempo definido. A través de este campo, se modela dicha característica. La
representación de este campo es tomada del campo “Periodicidad” del componente
Espacio/Temporal de MOCA.
Tabla 22. Resumen de la representación del componente de transacción de producto
ID TRANSFERENCIA
ID INTERRELACIÓN
ID CANAL
FECHA
Tran + Entero único
Referencia al identificador de
Referencia al
Ver el Campo
la interrelación de la
identificador del canal de
“Fecha” del
transferencia
distribución
componente Espacio
Temporal de MOCA
HORA
DURACIÓN
PERIODICIDAD
Ver el Campo “Hora” del
Ver el Campo “Duración” del
Ver el Campo “Periodicidad” del componente
componente Espacio
componente de Actividad de
Espacio Temporal de MOCA
Temporal de MOCA
MOCA
La Tabla 22 muestra el resumen de la representación que se tendrá encuentra para el componente de
transferencia de productos. Luego del análisis de la representación de este componente, se mostrará un
ejemplo que permita reconocer la información que en este componente se usa. La Tabla 23 muestra un
ejemplo tabulado, el cual representa una transferencia de productos, luego el Ejemplo 4 muestra la
representación lógica de dicho producto.
Tabla 23. Representación de la transferencia de archivos, dado por cierta interrelación entre compañías o
clientes.
ID TRANSFERENCIA
ID INTERRELACIÓN
ID CANAL
FECHA
Tran1
IR3
CA1
(24,12,2008)
HORA
DURACIÓN
PERIODICIDAD
{09,00,00}
<{hora,3}>
<{dia,7}>
ALM(Alm1;{10.000,kilos};<Prod1,Prod2,Prod20>;<Prod5,Prod7,Prod8>;<Pol25,Pol31>)
2.2.2.3.4.
Representación del componente de Servicio al Cliente
Ejemplo 15. Representación lógica del componente de transferencia de productos
Figura 33. Ontología del componente de servicio al cliente
La Figura 33 muestra la ontología definida para modelar el servicio al cliente dentro de una compañía. A
continuación se realizara una descripción de cada uno de los campos que hacen parte de dicha
representación.
1. Id Servicio: este campo representa un valor único y distintivo, que permite reconocer un
servicio al cliente, que estén registrados dentro del sistema. Para representar este campo se
utilizarán las siglas “SVC” y un valor entero único.
2. Usuarios asociados: cuando una empresa realiza un servicio al cliente, puede tener asociados
varios usuarios a dicho servicio, este campo se ocupa de mantener los datos de los usuarios
que están asociados a un servicio. Este campo se representará mediante una colección de ids
de los usuarios asociados.
3. Políticas asociadas: Cuando una empresa presta servicios de atención al cliente, estas
actividades deben estar asociados a unas políticas de servicio que sean pautadas por la
empresa que las realiza. Este campo se representara con una colección de ids que representan
las políticas asociadas (ver sección 2.2.2.2.2)
4. Tipo de servicio: mediante este campo se representará el tipo de servicio que pueda prestar
una empresa, este campo sera representada por medio de una secuencia de elementos. Una
taxonomía propuesta para esta tipificación se puede observar en la Figura 34.
Figura 34. Taxonomía de tipo de servicio al cliente
5.
Productos asociados: Cuando se prestan un servicio es posible que hayan productos asociados,
según sea el tipo de servicio que se está prestando, este campo puede que contener valores
nulos en algunos casos (e.g. sugerencias, es posible que no sea referente a un producto), sin
embargo, cuando se deben asociar producto, este campo se representará con una secuencia de
elementos que contienen los id de los elementos que están asociados a este servicio.
Tabla 24. Resumen de la representación del componente de servicio al cliente
CLIENTES
POLÍTICAS ASOCIADAS
TIPO DE SERVICIO
ASOCIADOS
“SVC”+ entero único Colección
de Colección de IDs de Secuencia asociada
correos electrónicos políticas asociadas al con los tipos de
servicio al cliente (ver servicio (ver Figura
sección 2.2.2.2.2)
34)
ID SERVICIO
PRODUCTOS
ASOCIADOS
Colección de los IDs
de los productos al
servicio al cliente.
La Tabla 24 muestra un resumen de la representación del componente de servicio al cliente. La Tabla 25,
representa un ejemplo tabulado de un servicio al cliente, específicamente una promoción de tres
productos, este servicio está asociado a seis usuarios, y finalmente este servicio al cliente tendrá pautas
que se verán reflejadas en las políticas asociadas al servicio. En el Ejemplo 16 se realiza la representación
lógica del ejemplo antes mencionado.
Tabla 25. Representación de un ejemplo tabulado, para un servicio al cliente relacionado con la promoción de 3
productos
ID SERVICIO
CLIENTES ASOCIADOS
POLÍTICAS
TIPO DE SERVICIO
PRODUCTOS
ASOCIADAS
ASOCIADOS
SVC1
<angela.carrillo@javeriana.edu.co,
<Pol26, Pol30>
[OfertaPromoción]
<PROD23,
cristanchoj@javeriana.edu.co,
PROD42,
andres-romero@javeriana.edu.co,
PROD10>
aragon@javiernana.edu.co,
david.marin@javeriana.edu.co,
lnino@javeriana.edu.co>
ALM(Alm1;{10.000,kilos};<Prod1,Prod2,Prod20>;<Prod5,Prod7,Prod8>;<Pol25,Pol31>)
Ejemplo 16. Representación lógica de un ejemplo relacionado con el componente de servicio al cliente
2.2.2.4.
Representación del Módulo Comunidad
En esta sección se irá mostrando uno a uno la representación lógica de los componentes del módulo
Comunidad. Además de la representación lógica, se mostrarán las ontologías establecidas para cada uno
de los componentes pertenecientes al módulo y las taxonomías establecidas para algunos de sus
campos.
2.2.2.4.1.
Representación del Componente de Roles
Figura 35: Ontología del Componente Rol
La Figura 28 muestra la ontología definida para representar los roles dentro MAICO. A continuación se
realizará una descripción de cada uno de los campos que hacen parte de dicha representación.
1.
2.
3.
Identificador del ROL (Id): Valor único y distintivo entre todas los roles registrados en el
sistema, utilizado para diferenciar, reconocer, y asociar el rol dentro de otros componentes.
Comunidad Dueña del Rol: Los roles que se modelan en MAICO están asociados a una única
comunidad (que es la que lo representa). A través de este campo se representa para cada rol,
cual es la comunidad asociada a dicho rol.
Nombre: Denominación verbal que se utiliza a nivel internamente de una comunidad para
reconocer los diferentes roles que existen dentro de la misma.
4.
Tipo Rol: Campo que tiene como objetivo realizar una primera diferenciación entre todos los
roles. Cada tipo de rol maneja diferentes privilegios dentro de una comunidad y se le aplican
diferentes restricciones normas y políticas.
Figura 36: Taxonomía de tipos de Roles
La Figura 36 muestra la caracterización de tipos de rol propuesta para utilizar dentro de IAM.
Como se puede apreciar en la ilustración, existen dos grupos principales de roles. En primer
lugar, se encuentran los usuarios Administradores cuya labor principal consiste en gestionar a
los miembros de la comunidad y su conducta dentro de la misma. Todas las comunidades
tienen un rol por defecto denominado el Administrador Total. Este rol es asignado
inicialmente al creador (pero él puede asignarlo a más usuarios) y posee todos los privilegios y
permisos sobre la comunidad. Si se considera conveniente, el creador puede crear
Administradores Parciales al que se le asignan ciertos privilegios y permisos del Administrador
total.
Por otra parte, se encuentra el rol de tipo Usuario que se divide en registrado y anónimo. Los
usuarios registrados son aquellos que comparten su información personal dentro del grupo y
en algunos casos, están facultados para consumir los productos y servicios que en este se
ofrecen (a los cuales se les distingue como consumidores). Mientras que los anónimos no
comparten la información y no poseen la facultad de consumir o utilizar los productos y
servicios dentro del grupo.
Tanto los usuarios registrados como los anónimos pueden ser contribuyentes. Los
contribuyentes son los que le realizan algún aporte a la comunidad (en las comunidades
virtuales el aporte suele ser de información, en las no virtuales el aporte puede ampliarse a más
contextos). Los dos tipos de contribuyentes identificados son los proveedores y los probadores.
El proveedor aporta a la comunidad materias primas para su funcionamiento (en comunidades
físicas como las ciudades los vendedores de las tiendas podrían ser considerados proveedores,
en las comunidades virtuales los proveedores suelen ser los usuarios que brindan información
dentro de la comunidad), mientras que el probador suele ser un usuario que tiene la labor de
evaluar y revisar la calidad del material provisto por el proveedor.
Para representar este campo se utilizará la misma estrategia que se utilizó en la descripción del
campo tipo del módulo de Información General (ver sección 2.2.2.2) pero en este caso no será
necesario llegar al último nivel de detalle dentro de la representación ya que en ciertos
grupos se le suele asignar más de un privilegio a sus usuarios. Por ejemplo, comunidades como
el Facebook20 están llenas de usuarios que en algún momento son consumidores(al buscar y
leer información) y en otro momento son productores (ya que trasmiten información a otros
miembros e inclusive toman el rol de probadores al hacer notificaciones o reportes por
contenido soez u ofensivo).
A continuación se muestra un ejemplo de la representación del campo tipo (Ejemplo 12). El
primer ejemplo (A) muestra una representación de un tipo detallado de usuario registrado.
Obedeciendo a la segunda regla de representación descrita anteriormente, el ejemplo B
20
www.facebook.com
muestra una representación de un usuario registrado que posee todos los privilegios de los
niveles inferiores (Consumidor y Contribuyente en este caso).
A. [usuarioregistradoconsumidorgratuito]
B. [usuarioregistrado]
Ejemplo 17: Representación Lógica del Campo Tipos de Rol
Tabla 26: Resumen de la Representación de los Roles
COMUNIDAD DUEÑA DEL ROL
NOMBRE
TIPO DE ROL
Referencia al Identificador de la
Elemento Simple
Ver Figura 36 y
21
comunidad
Ejemplo 12
ID
R+ Valor Entero no
repetido.
LISTADO DE USUARIOS
Colección de correos electrónicos
de los usuarios.
La Tabla 26 muestra un resumen de la representación del componente de Roles. La Tabla 27 muestra un
ejemplo tabulado de la representación del rol de estudiantes de proyecto especial y el Ejemplo 13
muestra la representación lógica.
ID
R3
Tabla 27: Ejemplo de Representación del Grupo de Proyecto Especial de personalización en el Componente de
Roles
COMUNIDAD
NOMBRE
TIPO DE ROL
LISTADO DE USUARIOS
DUEÑA DEL ROL
C1
Estudiantes de PE de
[usuarioregistrado]
<cristanchoj@javeriana.edu.co,Fernando.aragon@javeriana.edu.co,
personalización
david.marin@javeriana.edu.co,andres-romero@javeriana.edu.co >
ROL[R3;C1;Estudiantes Proyecto Especial Personalización;
[usuarioregistrado];<cristanchoj@javeriana.edu.co,Fernando.aragon@javeriana.edu.co,david.mar
in@javeriana.edu.co,andres-romero@javeriana.edu.co>]
Ejemplo 18: Representación Lógica del Grupo de Estudiantes de Proyecto Especial de Personalización en el
módulo de Roles
2.2.2.4.2.
Representación del Componente de Hábitos
Figura 37: Ontología del Componente Hábito
La Figura 37 muestra la ontología definida para modelar los hábitos dentro MAICO. A continuación se
realizará una descripción de cada uno de los campos que hacen parte de dicha representación.
8.
Identificador del Hábito: Valor único y distintivo entre todos los hábitos registrados en el
sistema. Utilizado para diferenciar, reconocer, y asociar el cada uno de los hábitos dentro de
otros componentes. Para representar este campo se utilizarán las siglas “Ha” y un entero único.
9. Comunidad a la que pertenece: Los hábitos que se modelan en MAICO están asociados a una
única comunidad (que a su vez es la que hace la representación del hábito a través del
componente). A través de este campo se representa cual es la comunidad asociada, utilizando
una referencia al identificador del componente de Información General.
10. Tipo de Hábito: Campo que tiene como objetivo hacer una primera diferenciación entre las
características de cada uno de los hábitos. Este campo es necesario dentro de este componente
para determinar si es necesario o no modelar normas que validen el cumplimiento de dicho
hábito. Los tipos de hábito definidos para MAICO son:
21
El identificador de la comunidad se representa en el campo Id del Componente de Información
General
11.
12.
13.
14.
15.
Obligatorio: Un hábito de estas características debe hacerse por todos los miembros
de la comunidad en la fecha asignada para realizarlo.
Voluntario: A diferencia del obligatorio, este tipo de hábito puede hacerse o no
hacerse. La decisión de si el hábito se realiza o no depende de cada uno de los
miembros de la comunidad.
Inconsciente: Los hábitos de esta clase no son definidos por los miembros de la
comunidad sino que son producto de comunicaciones entre MAICO y el Perfil
Contextual. Un hábito de este tipo se caracteriza por ser una actividad que es realizada
por todos los miembros de la comunidad aunque estos desconocen que la comparten.
Para la representación de este campo se utiliza un elemento simple con alguno de los nombres
anteriormente mencionados según el tipo del hábito que corresponda.
Nombre de Actividad: Denominación verbal de la actividad relacionada con el hábito que se
modela. La representación de este campo es tomada del campo “Nombre Actividad” del
componente de Actividad de MOCA.
Fecha: Define el día exacto en que entra en vigencia el hábito. Es decir el día en el cual el hábito
empieza a realizarse. La representación de este campo es tomada del campo “Fecha” del
componente Espacio/Temporal de MOCA.
Hora: Define la hora exacta en la que entra en vigencia el hábito. Es decir, la hora en la cual el
hábito empieza a realizarse. La representación de este campo es tomada del campo “Hora” del
componente Espacio/Temporal de MOCA.
Duración: Algunos hábitos establecen un lapso de tiempo en el cual se desarrolla la actividad.
Por ejemplo el hábito “Los jugadores de millonarios suelen trotar todas las mañanas de 7 a 9”
define una duración de 2 horas para realizar esta actividad. A través de este campo se modela
esta característica. La representación de este campo es tomada del campo “Duración” del
componente de Actividad de MOCA.
Periodicidad: Una de las características del hábito radica en ser una actividad que suele
repetirse tras un periodo de tiempo definido. A través de este campo se modela dicha
característica. La representación de este campo es tomada del campo “Periodicidad” del
componente Espacio/Temporal de MOCA.
ID
Ha+ Entero único
FECHA
Ver el Campo “Fecha” del
componente Espacio
Temporal de MOCA
Tabla 28: Resumen de la Representación de los Hábitos
COMUNIDAD A LA QUE
TIPO DE HÁBITO
NOMBRE ACTIVIDAD
PERTENECE
Referencia al
Elemento simple con alguno de los
Ver el Campo “nombre Actividad” del
Identificador de la
siguientes valores: “obligatorio”,
componente de Actividad de MOCA
comunidad
”voluntario” ó ”inconsciente”
HORA
DURACIÓN
PERIODICIDAD
Ver el Campo “Hora” del
Ver el Campo “Duración” del
Ver el Campo “Periodicidad” del
componente Espacio
componente de Actividad de MOCA
componente Espacio Temporal de
Temporal de MOCA
MOCA
La Tabla 28 muestra un resumen de la representación del componente de Hábitos. La Tabla 29 muestra
un ejemplo tabulado de la representación de un hábito presente en el grupo de proyecto especial y el
Ejemplo 14 muestra la representación lógica. En este ejemplo se representó el hábito de este grupo de
reunirse los martes de 11 a 1pm.
Tabla 29: Ejemplo de Representación del Hábito “Reunión el Martes de 11 a 1” (perteneciente al Grupo de Proyecto Especial de
personalización) en el Componente de Hábitos
ID
COMUNIDAD A LA QUE
TIPO DE HÁBITO
NOMBRE ACTIVIDAD
PERTENECE
Ha1
C1
obligatorio
Reunión del grupo de Proyecto Especial
FECHA
HORA
DURACIÓN
PERIODICIDAD
{22,07,2008}
{09,00,00}
<{hora,2}>
<{dia,7}>
HAB(Ha1;C1;obligatorio;Reunión de grupo de Proyecto Especial;
{22,07,2008};{09,00,00};<{hora,2}>;<{dia,7}>)
Ejemplo 19: Representación Lógica del Hábito “Reunión el Martes de 11 a 1” (perteneciente al Grupo de Proyecto
Especial de personalización) en el Componente de Hábitos
2.2.2.4.3.
Representación del Componente de Normas
Figura 38: Ontología del Componente Norma
La Figura 38 muestra la ontología definida para modelar las Normas dentro MAICO. A continuación se
realizará una descripción de cada uno de los campos que hacen parte de dicha representación.
1.
2.
3.
4.
5.
6.
7.
22
Identificador de la Norma (Id): Valor único y distintivo entre todas las normas registradas en el
sistema. Utilizado para diferenciar, reconocer, y asociar la norma dentro de sí misma (a través
del campo de condiciones) y dentro de otros componentes. Para representar este campo se
utilizarán las siglas No y un entero único.
Comunidad a la que pertenece: Las normas que se modelan en MAICO están asociadas a una
única comunidad (que a su vez es la que hace la representación de la norma a través del
componente de normas). A través de este campo se representa cual es la comunidad asociada,
utilizando una referencia al identificador del componente de Información General.
Política Asociada: Como se explicó en la sección 2.2.1.3, las normas son un enriquecimiento de
las políticas que además de definir las directrices del comportamiento dentro de la comunidad,
tienen en cuenta otros aspectos como las consecuencias de no cumplir dicha política, o los
casos excepcionales, entre otros. A través de este campo se referencia la política que se está
enriqueciendo para convertirla en norma. La referencia se representa mediante el Identificador
de la política22 sobre la que se está modelando la norma.
Usuarios a los que aplica: En las comunidades no todas las normas se aplican para todos sus
miembros haciendo importante identificar a que usuarios se les aplica. A través de este campo
se representará sobre que usuarios de la comunidad se aplica la norma. Para realizar la
representación de este campo se utilizará un elemento compuesto de dos elementos:
Colección de Usuarios: Listado con los identificadores de los usuarios que deben
seguir la norma.
Colección de Roles23: Listado con los identificadores de los roles que deben seguir la
norma.
Usuarios que la validan: Así como en la norma existen usuarios sobre los que se aplica la
norma, suele existir usuarios asignados por la comunidad para garantizar que la norma se
cumpla y para penalizar a los que no la cumplen. En este campo se colocan los usuarios que
tienen asignada esa tarea. La representación de este campo es igual a la explicada en el
numeral 4 de esta misma sección.
Condiciones: No todas las normas son restricciones en el comportamiento de los miembros de
la comunidad. De hecho, algunas de estas representan los derechos que tienen algunos
miembros dentro de la comunidad. Este tipo de normas suele tener restricciones asociadas
denominadas condiciones. Para representar dichas condiciones se utilizará una colección con
identificadores de normas (la condición debe inicialmente ser modelada en otra norma).
Excepciones: Puede que en alguna ocasión a cierto grupo de usuarios sobre los que aplica la
norma esté en facultad de incumplirla porque la comunidad lo considere conveniente. Este tipo
de situaciones suceden cuando a uno o más individuos se les da un permiso o una cláusula
especial que los excluye del cumplimiento de la norma por un tiempo definido o indefinido.
El Identificador de la política se representa en el campo “Id” del Componente de Políticas
El listado de roles se utiliza para reducir la dimensión de la representación del campo cuando la norma
es aplicada para muchos usuarios. En ese caso se sugiere agrupar los usuarios en roles y colocar la
referencia del rol en la colección de roles.
23
Para poder modelar ésta característica se utilizará un elemento compuesto de los siguientes
parámetros:
Lapso de tiempo: Puede que la excepción no se aplique en todo momento del día. De
hecho se podría dar la situación en la que el permiso para incumplir la norma solo se le
adjudique a los beneficiarios por un par de horas. A través de este campo se modelará
esa posibilidad, para ello se utilizará un campo compuesto con la hora inicio y la hora
fin de dicho lapso. Para representar estos dos elementos se utilizará la representación
del campo “hora” del módulo espacio temporal de MOCA.
Beneficiarios: En este campo irán asociados los usuarios sobre los que se aplica la
excepción. Para representar esto se utilizará una colección con identificadores de
usuarios.
Fecha de expedición: Este campo representa la fecha en la que entra en vigencia la
excepción. Este campo es necesario porque el día en el que se modela la excepción no
siempre es el mismo día en el que esta entra en vigencia. La representación de este
campo es tomada del campo “Fecha” del componente Espacio/Temporal de MOCA.
Fecha de vencimiento: Puede que la excepción sea asignada a los beneficiarios por un
tiempo definido. En ese caso se utilizará este campo para representar el día en el que
perderá la vigencia la excepción. La representación de este campo es tomada del
campo “Fecha” del componente Espacio/Temporal de MOCA.
Periodicidad: Puede que la excepción no tenga efecto todos los días durante su
periodo de vigencia. De hecho, e puede dar el caso en el que la excepción solo aplique
para unos días en especial. Por ejemplo puede existir una excepción que se aplica
únicamente los días lunes. Tomando en cuenta esta posible característica de las
excepciones, este campo la modelará. La representación de este campo es tomada del
campo “Periodicidad” del componente Espacio/Temporal de MOCA.
ID
No+ Entero único
USUARIOS QUE LA VALIDAN
{<Colección de
identificadores de usuarios.>
, <Colección de Roles>}
Tabla 30: Resumen de la Representación de las Normas.
COMUNIDAD A LA QUE PERTENECE
POLÍTICA ASOCIADA
USUARIOS A LOS QUE APLICA
Referencia al Identificador de la
Identificador de la política.
{<Colección de identificadores de
comunidad
usuarios.> , <Colección de Roles>}
CONDICIONES
EXEPCIONES
Colección con identificadores de
{{Representación del campo “hora” de MOCA, Representación del campo
normas
“hora” de MOCA},<colección con identificadores de usuarios>,
Representación del campo Fecha de MOCA, Representación del campo
Fecha de MOCA ,Representación del campo Periodicidad de MOCA}
La Tabla 30 muestra un resumen de la representación del componente de Normas y el Ejemplo 15
muestra una ejemplificación de este campo. Para este caso se utilizó representó la norma del Grupo de
Proyecto especial en la que se especifica que los estudiantes (De rol R3) deben asistir a la reunión que se
celebra todos los martes de 9 a 11.
NOR(No1;C1;Pol2;R3;angela.carrillo@javeriana.edu.co,NULL,NULL)
Donde Pol2 = POL(Pol2;C1;[actividad asociadapermitida];Reunión de 9 a
11(*);angela.carrillo@javeriana.edu.co)
(*): La actividad con este nombre debe modelarse dentro de MOCA.
Ejemplo 20: Representación Lógica del Hábito “Reunión el Martes de 11 a 1” (perteneciente al Grupo de Proyecto
Especial de personalización) en el Componente de Hábitos
2.2.3. Adquisición
En la sección anterior se realizó una descripción detallada de cada uno de los componentes de MAICO
especificando como se representa cada uno de ellos. En esta sección se explicara los mecanismos de
adquisición de la información necesaria para modelarlos y representarlos.
2.2.3.1.
Mecanismos de Adquisición
Antes de realizar la asociación entre los componentes y los mecanismos de adquisición que serán
utilizados para cada uno de ellos es de vital importancia definir qué mecanismos serán los que se
utilizarán. En esta sección se enunciarán los mecanismos que serán utilizados para adquirir la
información dentro de MAICO. Dichos mecanismos son:
Interfaz.
Formulario.
Bases de Datos de los grupos: Conjunto de datos pertenecientes a cada uno de los grupos que
suelen ser utilizadas en los sistemas de información de las empresas y en los portales de las
comunidades virtuales.
Historiales Web: Registros almacenados en las páginas de los grupos sobre el comportamiento
y las acciones que realizan sus miembros.
Historiales de Compra: Registros que tienen las empresas enfocadas en las ventas sobre las
compras que realizan sus usuarios. Estos historiales pueden estar o pueden hacer parte del
sistema de información de la compañía.
Información Corporativa: La información corporativa comprende el grupo de archivos digitales
o físicos que posee una empresa sobre sí misma. En la información corporativa suele ir
registrada las características y estructura de una compañía así como la reglamentación y
descripción de los procesos que se realizan dentro de ella.
Comunicación con otros módulos: Algunos de las representaciones dentro de MAICO se
producen al interactuar con otros componentes de la arquitectura de IAM. Los hábitos por
ejemplo pueden ser representados de dos formas. La primera es a través de la representación
del hábito por parte de uno de sus miembros y la segunda es a través de la solicitud a MOCA de
posibles actividades compartidas entre los usuarios del a comunidad. La segunda forma de
representación utiliza este mecanismo para adquirir la información.
2.2.3.2.
Adquisición del Módulo Componentes Compartidos
Las primeras representaciones que se describieron a lo largo de este documento correspondían al
módulo de Componentes Compartidos. A lo largo de esta sección se describirá como se adquirirá la
información para realizar dichas representaciones.
2.2.3.2.1.
Adquisición del Componente de Información General
La información necesaria para representar el componente de Información general será adquirida
mediante:
Formulario.
Interfaz.
2.2.3.2.2.
Adquisición del Componente de Políticas
La información necesaria para representar el componente de Políticas será adquirida mediante:
Formulario.
Interfaz.
Bases de Datos de los grupos.
Información Corporativa.
2.2.3.2.3.
Representación de Preferencias Sociales
La información necesaria para representar el componente de Preferencias Sociales será adquirida
mediante:
Formulario.
Interfaz.
2.2.3.2.4.
Representación del Componente de Interrelación
La información necesaria para representar el componente de Preferencias Sociales será adquirida
mediante:
Interfaz.
Bases de Datos de los grupos.
Información Corporativa.
2.2.3.2.5.
Representación del Componente Institucional
La información necesaria para representar el componente institucional será adquirida mediante:
Interfaz.
Historiales Web.
Bases de Datos de los grupos.
Información Corporativa.
2.2.3.3.
Adquisición del Módulo Empresarial
A lo largo de esta sección se describirá como se adquirirá la información para realizar dichas
representaciones del módulo empresarial. Como se menciono en la sección 2.2.1.2 este módulo se
compone de 5 componentes: El de canal, producto, logística, servicio al cliente, y mercadotecnia y
ventas. Los mecanismos de adquisición de cada uno de éstos se realizarán a lo largo de esta sección en
ese mismo orden.
2.2.3.3.1.
Adquisición del Componente Canal
La información necesaria para representar el componente de Canal será adquirida mediante:
Interfaz.
Formulario
Información Corporativa.
2.2.3.3.2.
Adquisición del Componente Producto
La información necesaria para representar el componente de Producto será adquirida mediante:
Interfaz.
Formulario
Información Corporativa.
Historiales de compra
2.2.3.3.3.
Adquisición del Componente Logística
Puesto que el componente de logística esta dividió en dos componentes, (uno denominado componente
de almacenamiento y el otro de transferencia de productos) la adquisición de la información es posible
que se lleve a cabo de manera distinta, las cuales serán descritas a continuación:
A.
Adquisición del Componente Almacenamiento
La información necesaria para representar el componente de Almacenamiento será adquirida mediante:
Interfaz.
Formulario
Información Corporativa.
B.
Adquisición del Componente Transferencia de Productos
La información necesaria para representar el componente de transferencia de productos será adquirida
mediante:
Interfaz.
Formulario
Información Corporativa.
Historial de compras.
Comunicación con otros módulos.
2.2.3.3.4.
Adquisición del Componente Servicio al Cliente
La información necesaria para representar el componente de transferencia de Servicio al cliente será
adquirida mediante:
Interfaz.
Formulario
Información Corporativa.
Historial Web
Historial de compras.
Comunicación con otros módulos.
2.2.3.3.5.
Adquisición del Componente de Mercadotecnia y ventas
La información necesaria para representar el componente de Mercadotecnia y ventas será adquirida
mediante:
Formulario
Información Corporativa.
Historial Web
Historial de compras.
2.2.3.4.
Adquisición del Módulo Comunidad
A lo largo de esta sección se describirá como se adquirirá la información para realizar dichas
representaciones del módulo de comunidad. Como se menciono en la sección 2.2.1.3 este módulo se
compone de 3 componentes: El de roles, hábitos y normas. Los mecanismos de adquisición de cada uno
de éstos se realizarán a lo largo de esta sección en ese mismo orden.
2.2.3.4.1.
Representación del Componente de Roles
La información necesaria para representar el componente de roles será adquirida mediante:
Interfaz.
Formulario.
Bases de Datos de los grupos.
Historiales Web.
Información Corporativa.
2.2.3.4.2.
Representación del Componente de Hábitos
La información necesaria para representar el componente de hábitos será adquirida mediante:
Interfaz.
Formulario.
Historiales Web.
Historiales de Compra.
Comunicación con otros módulos.
2.2.3.4.3.
Representación del Componente de Normas
La información necesaria para representar el componente de normas será adquirida mediante:
Interfaz.
Formulario.
Bases de Datos de los grupos.
Información Corporativa.
2.3.
Relaciones
Una de las fortalezas de IAM radica en la interacción de todos sus componentes. Gracias a esta
interacción los resultados de cada uno de sus componentes poseen un mayor alcance aplicativo que
permiten el uso del modelo para varias situaciones logrado por otros autores. Para lograr este cometido,
es de vital importancia definir claramente los mecanismos de comunicación entre cada uno de los
módulos, identificando los componentes que se van a relacionar, el objetivo de la relación y la
información que van a intercambiar.
Las relaciones entre MAICO y los demás módulos se realizan de dos formas. En la primera, MAICO toma
el rol de proveedor de información brindando información a los demás módulos de IAM. En la segunda
forma, MAICO toma el rol de cliente y recibe información provista por los demás módulos de IAM. Estos
dos mecanismos por los que se relaciona MAICO serán descritos a continuación.
2.3.1. MAICO como Proveedor
Como proveedor de información MAICO se relaciona con dos módulos de IAM: MOCA y MAIPU. A
continuación se describirá como se realiza dicha relación.
2.3.1.1.
Relación con MOCA
Figura 39. Relación entre MAICO y MOCA donde MAICO toma el rol de Proveedor
Como se puede apreciar en la Figura 32 la relación entre MAICO y MOCA donde MAICO toma el rol de
Proveedor de Información se da entre 2 componentes de cada módulo. Dichas relaciones son:
Relación entre el Componente de Información General y el Componente Espacio/Temporal:
Como se pudo apreciar en la sección 2.2.2.2.1, uno de los campos que hacen parte del
componente de información general es el de ubicación. Teniendo en cuenta que la ubicación es
modelada por MOCA, cada vez que una comunidad es creada dentro de IAM a través de MAICO
este le envía la información al componente Espacio/Temporal de MOCA quien es el encargado
de representar dentro de este componente la ubicación de la comunidad. Después de que
MOCA lo representa, devuelve a MAICO una referencia a dicha representación a través de un Id
de comunicación.
Relación entre el Componente de Hábitos y Actividad: Una de las características de MAICO es
la capacidad de identificar hábitos inconscientes24 dentro de los miembros de la comunidad.
Para esto, MAICO le provee la lista de los usuarios miembros de la comunidad. Con esta
información MOCA busca actividades que comparten todos los usuarios para que sean
modeladas como hábitos. La información devuelta por MOCA hacia MAICO se muestra en la
sección 2.3.2.1.
La información que se va a intercambiar en las dos relaciones anteriormente descritas se muestra en la
Tabla 31.
Tabla 31. Información provista por los componentes de MAICO a los componentes de MOCA
PROVEEDOR
CLIENTE
DATOS A INTERCAMBIAR
FORMATO DE ENVÍO
MAICO
MOCA
El tipo de ubicación del grupo
Información
Espacio/Temporal
tipo ubicación; valor 25
General
El valor asociado al tipo de la
ubicación
Listado con identificadores de
Hábitos
Actividad
<id de usuarios >
usuarios de la comunidad
(
)
(
24
)
Un hábito inconsciente es una actividad que todos los miembros de la comunidad realizan pero no lo
saben.
25
El cliente utiliza esta información para crear una ubicación y le retorna al proveedor una referencia del id de la
ubicación creada.
2.3.1.2.
Relación con MAIPU
Figura 40. Relación entre MAICO y MAIPU donde MAICO toma el rol de Proveedor
Como se puede apreciar en la Figura 33, la relación con MAIPU en la que MAICO es proveedor de
información sucede a partir de 2 interacciones entre 2 componentes de cada uno de los modelos. Dichas
relaciones son:
Relación entre el Componente de Políticas y el Componente de Preferencia de Resultados:
Una de las políticas que se puede modelar dentro de una comunidad representa las
preferencias de ésta para desplegarles la información a sus usuarios. A través de esta
comunicación MAICO le comunica a MAIPU que información va a ser desplegada, a que
usuarios y por medio de que canales de despliegue de información. Utilizando esta información
MAIPU despliega la información a cada uno de los usuarios teniendo en cuenta las preferencias
personales de cada uno de ellos.
Relación Entre el Componente de Información General y el Componente de Preferencia de
Actividades Relacionadas: Para poder modelar las preferencias de actividades relacionadas en
MAIPU, este componente necesita conocer las comunidades a las que pertenecen los usuarios.
Mediante esta comunicación se resuelve esa necesidad ya que dado el identificador de un
usuario, el componente de información general buscará las comunidades a las que pertenece
dicho usuario. Posteriormente dicha información se la entregará al componente de preferencia
de actividades relacionadas.
Relación entre el Componente de Hábitos y el de Preferencias de Actividad: Como ya se ha
explicado anteriormente, un hábito dentro de MAICO es una actividad compartida por todos los
usuarios (ver Sección 2.2.1.3). Sin embargo, cada uno de los usuarios pueden ejecutar esa
actividad de manera diferente según sus preferencias. Teniendo en cuenta esta característica,
MAICO y MAIPU establecen una comunicación entre estos dos componentes cuyo objetivo es
modelar la actividad en el listado de tareas pendientes de cada usuario. Para esto, MAICO le
envía a MAIPU los usuarios, la actividad y la fecha límite para ejecutar dicha actividad. Con esta
información MAIPU modela la actividad a cada uno de los usuarios (dentro del componente de
preferencias de actividad) para informar al usuario que su realización está pendiente,
especificando las tareas que debe realizar para cumplirla(tareas que serán priorizadas según
sus preferencias).
La información que se va a intercambiar en las tres relaciones anteriormente descritas se muestra en la
Tabla 32.
Tabla 32. Información provista por los componentes de MAICO a los componentes de MAIPU
PROVEEDOR
CLIENTE
DATOS A INTERCAMBIAR
FORMATO DE ENVÍO
MAICO
MAIPU
Elemento Compuesto de:
Políticas
Preferencia
de resultados
Colección de Usuarios que van a recibir
información de la comunidad
({<id de usuarios>;<tipo de canal>})
Canales por los que los usuarios puede
recibir información de una comunidad
Información
general
Hábitos
Preferencia
de actividades
relacionadas
Preferencias
de Actividad
Colección de Elementos Compuestos de:
Un identificador de usuario
Identificador de las Comunidades a las que
dicho usuario pertenece
Colección de Usuarios que deben realizar el
hábito.
Nombre de la actividad asociada al hábito
(<{id de usuarios,<comunidades>}>)
(<id de usuarios>;nombre
actividad;{día,mes,año};{hora,minuto,
segundos})
Fecha y hora límite para realizar la actividad
2.3.2. MAICO como Cliente
Cuando MAICO toma el rol de cliente se relaciona únicamente con MOCA. A continuación se mostrará
cómo se realiza dicha relación
2.3.2.1.
Relación con MOCA
Figura 41. Relación entre MAICO y MOCA donde MAICO toma el rol de Cliente
Como se puede apreciar en la Figura 34, la relación entre MAICO y k donde MAICO toma el rol de cliente
de se da entre 2 componentes de cada módulo. Dichas relaciones son:
Relación entre el Componente Espacio/Temporal y el de Información General: Cuando alguno
de los usuarios de IAM requiera la información general de la comunidad es necesario mostrarle
la ubicación de dicha comunidad. Es por esto que MAICO solicita la información de la ubicación
generada en la relación mostrada en la sección 2.3.1.1. Para ello, entrega al componente
Espacio/Temporal de MOCA la referencia del identificador de la ubicación y este componente le
devuelve a MAICO la información de la ubicación.
Relación entre el Componente de Actividad y Hábitos: Continuando con la relación descrita en
la sección 2.3.1.1, después de que el componente de actividad de MOCA recibe el listado de
usuarios, éste realiza una búsqueda de actividades compartidas por todos esos usuarios. En
caso de encontrar una o más actividades, le devuelve un listado con la siguiente información
(por cada actividad) a MAICO: El nombre, la fecha, la hora, la duración y la periodicidad de la
actividad asociada a la actividad.
La información que se va a intercambiar en las dos anteriormente descritas relaciones se muestra
en la Tabla 33.
Tabla 33. Información provista por los componentes de MOCA a los componentes de MAICO
PROVEEDOR
CLIENTE
DATOS A INTERCAMBIAR
FORMATO DE ENVÍO
MOCA
MAICO
26
Tipo de ubicación según el id de la ubicación
Espacio/Tem Información
tipo ubicación, valor
poral
General
Valor asociado a la ubicación relacionado con
el id de la ubicación
Colección de elementos compuestos. Cada
elemento compuesto se compone de:
(
Nombre de la Actividad
Actividad
Hábitos
Fecha de la actividad
Hora de la Actividad
Duración de la actividad
(<{nombre actividad,{día, mes, año, {HORA,} },
<{medida duración, valor}>,<{medida
periodicidad, valor}>
Periodicidad de la actividad
26
)
Antes de que el proveedor le envía la información al componente de Información General, MAICO le
envía al proveedor una referencia a un id de comunicación.
}>)
3. ROL DENTRO DE IAM
Figura 42. Ubicación del MAICO
Como se puede apreciar en la Figura 35, MAICO dentro de IAM hace parte del módulo de contenido. Su
rol es el de interactuar con el módulo individual y contextual para modelar comunidades. El modelado
de comunidades servirá para establecer cómo se va a manejar la información dentro de una comunidad
identificando principalmente las políticas y preferencias existentes que permitan diferenciar y
seleccionar la información que es de interés dentro de un contexto para la comunidad y sus miembros.
Además de esto, MAICO tiene el deber de enviarle las características de información a desplegar para
los miembros de la comunidad al módulo individual el cual determinará el mejor mecanismo de
despliegue dicha información junto con el módulo de despliegue.
4. ESCENARIOS
En esta sección se mostrarán algunos casos de estudio en los que se aplicará MAICO. Para ello, se
plantearon 5 escenarios que serán descritos y enunciados a continuación, destacando que componentes
de MAICO serán utilizados para modelar dichos casos.
4.1.Escenario 1
A. Definición del Escenario
Representación de un grupo orientado a la discusión, los debates y las ponencias.
B. Ejemplo que describe el Escenario
Se desea crear una comunidad virtual donde se traten gran variedad de temas y se analicen desde las
perspectivas de varias disciplinas. Dentro de la comunidad existirán dos tipos principales de usuarios: 1)
Aquellos que poseen algún estudio determinado que tendrán permisos para plantear temas y escribir
ensayos dentro de la comunidad y 2) Aquellos que no poseen estudios en un área determinada pero a
los que les llama la atención el tema y están interesados en leer y opinar sobre los ensayos y las
ponencias. En esta comunidad los usuarios suelen tener una conversación virtual semanalmente en la
que se establece un tema de actualidad (como por ejemplo el alcoholismo) con el cual los diferentes
usuarios plantean su punto de vista de acuerdo su disciplina. Debido a la complejidad de los temas que
se tratan en esta comunidad, se exige a sus usuarios ser mayores de 18 años y poseer estudios mínimos
de educación secundaria.
C. Componentes que se utilizan de MAICO
Figura 43. Componentes Utilizados en el Caso de Estudio 1
La Figura 36 muestra los componentes que se utilizan para modelar este caso de estudio. A continuación
se listan que requerimientos cumple cada uno de los componentes:
Información General: Definir el tipo de comunidad y el sector en el que se desenvuelve (en
este caso el religioso)
Políticas: Establecer los temas que se tratan dentro de la comunidad. Establecer los permisos
de lectura y escritura sobre dichos temas para los diferentes usuarios.
Preferencias Sociales: Garantizar que los usuarios sean mayores de 18 años y posean
educación secundaria como mínimo.
Roles: Definir los dos tipos principales de usuarios.
Hábitos: Modelar la actividad que tienen cada 8 días los usuarios
Normas: Para garantizar que los usuarios hagan debido uso de sus facultades y no violen los
privilegios que se les asignan dentro de la comunidad.
La tabla que se muestra a continuación (Tabla 34) muestra los criterios que son tomados en cuenta en
27
el Escenario 1 , realizando una breve descripción que argumenta la toma en cuenta del criterio.
Finalmente en la última columna de la tabla se establecen que componentes proveen dicho criterio.
CRITERIO
Consideración del
Perfil Individual
Uso de Reglas
27
Tabla 34. Criterios tomados en cuenta dentro del Escenario 1.
DESCRIPCIÓN
COMPONENTE QUE LO PROVEE
Cada uno de los usuarios se desenvuelve en un temas de su
MAIPU: Este módulo modela los
preferencia
usuarios. La interacción individual
de los usuarios con la comunidad se
realizan teniendo en cuenta las
preferencias de cada uno de ellos se
son contempladas dentro de
MAIPU.
Que los usuarios hagan buen uso de las facultades según su tipo de
Políticas y Normas
usuario.
Los criterios están definidos en la sección 1.3. Los criterios que serán definidos para cada uno de los
escenarios descritos de aquí en adelante utilizarán esos criterios de dicha sección.
Clasificación por
Preferencias Sociales
Clasificación por
Comportamiento
Clasificación por
Temas de Interés
Identificación de
Roles dentro de la
comunidad
La comunidad exige que los usuarios sean mayores de edad y posean
estudios secundarios. Dentro de la comunidad se definen disciplinas
(profesiones) que son utilizadas para analizar los temas que dentro de
ella se define.
Los usuarios tienen un actividad semanalmente
Preferencias Sociales
La comunidad define unos temas de interés sobre los que realiza sus
ponencias. Los usuarios de la comunidad deben recibir información
relacionada preferiblemente con los temas que les competen e
interesan.
La comunidad define 2 tipos principales de usuarios: Los que realizan
los ensayos y plantean la ponencia a partir de ellos y los que opinan
sobre los ensayos y las ponencias.
Políticas / MAIPU
Hábitos
Roles
D. Forma de adquirir la información.
La adquisición de la información se realizará con los mecanismos descritos en la sección 2.2.3.1
asociados a cada uno de los componentes de MAICO que serán utilizados.
E. Aplicación del escenario a casos reales
El siguiente escenario puede aplicarse en:
1. Comunidades virtuales que interactúan a través de foros y tableros de discusión.
2. En el sistema de educación virtual donde el ingreso de los usuarios está condicionado
únicamente a los estudiantes que se matriculen en el curso.
F. Conclusiones del Escenario 1
Del escenario anteriormente descrito se puede concluir que:
1. MAICO provee a través de sus componentes solución a los requerimientos mínimos de la
comunidad (definidas en la Tabla 34).
2. Aunque MAIPU provee un servicio de temas de interés por usuario, MAICO en comunicación
con MAIPU podrían establecer una relación que enriquezca a IAM en la que a cada usuario
registrado se le brinden sugerencias (por correo electrónico por ejemplo) sobre comunidades
de su interés (teniendo en cuenta los temas que en éstas se abordan). Este servicio permitiría
que el usuario no tenga que buscar las comunidades por sí mismo.
4.1.1. Escenario 2
A. Definición del Escenario
Representación de un grupo de investigación con alto volumen de actividades e intereses de establecer
control sobre la realización y cumplimiento de dichas actividades.
B. Ejemplo que describe el Escenario
Un grupo de personas desean formar una comunidad en la web, para poder compartir los aportes que
han realizado en su investigación de interés común, además desean que en esta web se mantenga
calendarizado todas las actividades que se realizaran durante la investigación, incluso que tenga la
capacidad de avisar a sus miembros con antelación sobre las actividades que en esta se realizan. Esta
comunidad categorizará a los miembros de la comunidad por roles, los cuales tendrán ciertos permisos
sobre la información de la investigación. Para ser miembros de esta comunidad se deben seguir ciertos
requisitos que serán definidos por el(los) creador(es) de ésta. Para garantizar que los usuarios cumplan
con las labores exigidas por el grupo, se establecerán normas que garanticen que los usuarios realicen
su aporte a la investigación en una hora definida y que en caso de no cumplir, los usuarios sean
expulsados del grupo.
C. Componentes que se utilizan de MAICO
Figura 44. Componentes Utilizados en el Caso de Estudio 2
La Figura 37 muestra los componentes que se utilizan para modelar este caso de estudio. A continuación
se listan que requerimientos cumple cada uno de los componentes:
Información General: Definir el tipo de comunidad y el sector en el que se desenvuelve (en
este caso el de investigación y académico)
Políticas:
o Establecer los diferentes temas que se tratan dentro de la comunidad (En este caso los
temas están definidos por los temas de investigación en los que se desenvuelva el
grupo)
o Establecer el privilegio que tienen todos los usuarios de aportar en la comunidad a
través de las investigaciones que realicen.
Roles: Definir los diferentes tipos de usuarios que existen en la comunidad según los temas en
los que aportan en la investigación.
Hábitos: Definir las diferentes actividades que realizan los usuarios dentro del grupo.
Normas: Establecer los castigos o condiciones que se establecen cuando alguno de los usuarios
incumple las actividades pautadas dentro del grupo.
Institucional: Modelas la posible existencia de subgrupos en la comunidad.
La tabla que se muestra a continuación (Tabla 35) muestra los criterios que son tomados en cuenta en
el Escenario 2, realizando una breve descripción que argumenta la toma en cuenta del criterio.
Finalmente en la última columna de la tabla se establecen que componentes proveen dicho criterio.
CRITERIO
Consideración del Perfil
Individual
Uso de Reglas
Clasificación por
Comportamiento
Identificación de Roles
dentro de la comunidad
Consideración de “Sub
Comunidades”
Tabla 35. Criterios tomados en cuenta dentro del Escenario 2.
DESCRIPCIÓN
Cada usuario en la comunidad realiza un trabajo asignado por
el grupo. Aunque existen actividades compartidas, las tareas
de dichas actividades varían según el usuario.
Establecer las reglas de convivencia entre sus miembros
enfocadas principalmente en el control de entregables que
debe hacer cada uno de sus miembros.
Los usuarios comparten actividades dentro del grupo de
investigación como la realización de aportes a la investigación
(dichos aportes además deben entregarse en una fecha límite)
Modelar los diferentes tipos de usuarios que existen dentro del
grupo de investigación. Cada rol tendrá acceso a diferentes
temas de investigación dentro del grupo.
En caso de que existan pequeños grupos de investigación
dentro del gran grupo de investigación es necesario
diferenciarlos sin que el pequeño grupo no sea desvinculado
del gran grupo. El uso de sub grupos de investigación suele
COMPONENTE QUE LO PROVEE
COMUNICACIÓN CON MAIPU:
MAIPU a través del componente de
Preferencias de Actividad. (La
información es provista por el
componente hábitos de MAICO)
Normas
Hábitos
Políticas y Roles. Las políticas definen los
temas manejados por el grupo y los
permisos que se asignan a cada uno de
los temas mientras que los roles asocian
dichas políticas a los usuarios.
Institucional
tenerse en cuenta en proyectos de investigación grandes que
involucren la interacción de varias disciplinas.
D. Forma de adquirir la información.
La adquisición de la información se realizará con los mecanismos descritos en la sección 2.2.3.1
asociados a cada uno de los componentes de MAICO que serán utilizados.
E. Aplicación del escenario a casos reales
El siguiente escenario puede aplicarse en:
1. Los grupos de investigación universitarios
2. Los grupos de investigación (como COLCIENCIAS)
3. Los proyectos en los que intervengan varias personas y con tareas definidas. Un modelo como
éste facilitaría el control y el orden sobre las actividades que cada uno de los usuarios tiene
asignada dentro del grupo.
F. Conclusiones del Escenario 2
Del escenario anteriormente descrito se puede concluir que:
1. MAICO provee a través de sus componentes solución a los requerimientos mínimos de la
comunidad (definidas en la Tabla 35).
2. El uso de las instituciones permite modelar grupos que además de poseer las características
mínimas del escenario, incluya subgrupos de investigación interdisciplinarios dentro de un
mismo proyecto.
3. La toma en cuenta de las preferencias de usuario (a través de la comunicación con MAIPU)
permite que además de representarse el grupo dentro de IAM las actividades que se deben
cumplir dentro del grupo sean realizadas de acuerdo a las preferencias de cada uno de sus
usuarios. (Ver Sección 2.3.1.2)
4.1.2. Escenario 3
A. Definición del Escenario
Representación de una comunidad de aficionados que define roles según el nivel de afición e interactúa
con otras comunidades asociadas a la misma afición.
B. Ejemplo que describe el Escenario
Un grupo de personas que practican juegos de mesa, desean compartir sus experiencias en la web.
Dichos miembros podrán ser jugadores experimentados, principiantes, o que no conozcan del tema. Los
principiantes pueden únicamente acceder a la información que publican los usuarios experimentados e
intermedios. Por otro lado, los usuarios intermedios pueden aportar información sobre el juego de mesa
en el que se desenvuelvan pero su trabajo debe ser aprobado por al menos un usuario experimentado.
Por último, los usuarios experimentados no tienen ninguna restricción para publicar información. La
comunidad tiene un convenio con otra comunidad de juegos de mesa denominado GBoardGeek en el
cual ambas se comparten la información relacionada con el ajedrez. Toda la información de la
comunidad no puede ser vista por aquellos que no sean miembros.
C. Componentes que se utilizan de MAICO
Figura 45. Componentes Utilizados en el Caso de Estudio 3
La Figura 38 muestra los componentes que se utilizan para modelar este caso de estudio. A continuación
se listan que requerimientos cumple cada uno de los componentes:
Información General: Definir el tipo de comunidad y el sector en el que se desenvuelven tanto
la comunidad de ajedrez como la de GBoardGeek
Políticas:
o En la comunidad de Juegos de Mesa:
 Establecer los diferentes temas que se tratan dentro de la comunidad (ej
Ajedrez, Juegos de Rol, Parqués, Juegos de Azar)
 Establecer los diferentes privilegios que tienen los usuarios según su rol
(principiante, intermedio, avanzado).
 Establecer la política de distribución y recepción de información con el tema
de ajedrez.
o En GBoardGeek:
 Establecer los diferentes temas que se tratan dentro de la comunidad (ej
Ajedrez, Juegos de Rol, Parqués, Juegos de Azar)
 Establecer la política de distribución y recepción de información con el tema
de ajedrez.
Roles: Definir los 3 tipos de usuarios que exiten: Principiante, intermedio, avanzado.
Normas: Establecer los castigos o condiciones que se establecen cuando alguno de los usuarios
incumple las actividades pautadas dentro del grupo.
Interrelación: Modelar el convenio entre la comunidad y GBoardGeek de compartir
información relacionada con el tema ajedrez.
La tabla que se muestra a continuación (Tabla 36) muestra los criterios que son tomados en cuenta en el
Escenario 3, realizando una breve descripción que argumenta la toma en cuenta del criterio. Finalmente
en la última columna de la tabla se establecen que componentes proveen dicho criterio.
CRITERIO
Uso de Reglas
Clasificación por Temas
de Interés
Consideración de medios
de distribución
Identificación de Roles
dentro de la comunidad
Tabla 36. Criterios tomados en cuenta dentro del Escenario 3.
DESCRIPCIÓN
Cada uno de los usuarios tiene derechos distintos dentro del
grupo (según su tipo). Es necesario modelar estas pautas para
que el sistema restrinja automáticamente el acceso a la
información a cada uno de los usuarios.
El grupo desea establecer políticas de distribución y recepción
de la información asociadas con el tema “ajedrez”
Para el envío y trasmisión de la información es necesario
dentro de este grupo establecer los canales de trasmisión de la
información y de distribución.
Modelar los tipos de usuario (principiante , intermedio y
avanzado)
D. Forma de adquirir la información.
COMPONENTE QUE LO PROVEE
Normas y Políticas
Políticas e Interrelación
Políticas e Interrelación.
Roles
La adquisición de la información se realizará con los mecanismos descritos en la sección 2.2.3.1
asociados a cada uno de los componentes de MAICO que serán utilizados.
E. Aplicación del escenario a casos reales
El siguiente escenario puede aplicarse en:
1. Las comunidades de juegos (de video, de mesa, de rol, etc.) existentes en internet.
2. Las comunidades de música por género o de artistas de música.
3. Comunidad deportivas ya sea por el deporte en sí o por algún equipo o jugador que lo practica.
F. Conclusiones del Escenario 3
Del escenario anteriormente descrito se puede concluir que:
1. MAICO provee a través de sus componentes solución a los requerimientos mínimos de la
comunidad (definidas en la Tabla 36).
2. Además de los criterios enunciados en dicha tabla, el componente de interrelaciones de MAICO
le permite a la comunidad de este caso de estudio la opción de comunicarse con otras
comunidades para trasmitir y compartir información.
4.1.3. Escenario 4
A. Definición del Escenario
Representación de una microempresa con una pequeña línea de negocio que funciona en una única
ciudad.
B. Ejemplo que describe el Escenario
Una empresa importadora de juegos de video que se encuentra ubicada en Bogotá desea sistematizar
los procesos de importación y distribución de los productos de acuerdo a sus preferencias. El
establecimiento no tiene bodegas y por eso prefiere no manejar inventarios. Durante este año han
vendido tres tipos de productos: Juegos de nintendo wii, juegos de Ps3 y juegos de PC. Esta empresa
tiene un convenio con otra empresa que se encarga de vender los productos. Dicha empresa tiene dos
puntos de ventas ubicados en dos secciones distintas de la ciudad. Para cada punto se trabajan precios y
preferencias de stock diferentes. El canal de distribución que se utiliza siempre es el de transporte en
camión aunque los proveedores de los productos están considerando la posibilidad de utilizar avión.
C. Componentes que se utilizan de MAICO
Figura 46. Componentes Utilizados en el Caso de Estudio 4
La Figura 39 muestra los componentes que se utilizan para modelar este caso de estudio. A continuación
se listan que requerimientos cumple cada uno de los componentes:
Información General: Definir el tipo y el sector en el que se desenvuelve la empresa y los
puntos de venta.
Políticas: Modelar las políticas que la empresa establece con las puntos de venta.
Interrelación: Modelar los convenios entre la tienda de video juegos y los puntos de venta.
Canal: Modelar los canales de distribución que utiliza la empresa (inicialmente el camión)
Producto: Definir los 3 principales productos que ofrece la video tienda.
Logística: Modelas las preferencias que tiene la empresa en relación con el recibo y la
distribución de los productos.
La tabla que se muestra a continuación (Tabla 37) muestra los criterios que son tomados en cuenta en el
Escenario 4, realizando una breve descripción que argumenta la toma en cuenta del criterio. Finalmente
en la última columna de la tabla se establecen que componentes proveen dicho criterio.
CRITERIO
Consideración de medios
de distribución
Aplicación en Negocios
Tabla 37. Criterios tomados en cuenta dentro del Escenario 4.
DESCRIPCIÓN
A través de las políticas el grupo define las preferencias con
respecto a los medios de distribución y despacho de los
productos de la tienda.
Este escenario en particular no describe una relación entre
COMPONENTE QUE LO PROVEE
Políticas
Logística, Canal y Producto
D. Forma de adquirir la información
La adquisición de la información se realizará con los mecanismos descritos en la sección 2.2.3.1
asociados a cada uno de los componentes de MAICO que serán utilizados.
E. Aplicación del escenario a casos reales
El siguiente escenario puede aplicarse en:
1. Microempresas con poco número de sucursales.
2. Personas que deseen crear negocio (ya sea virtual o físico)
3. Las empresas intermediarias entre el proveedor y el negocio. A estas empresas les puede servir
este modelo para atender las demandas del negocio según sus preferencias y para sugerir y
seleccionar los proveedores adecuados para cada una de las empresas.
F. Conclusiones del Escenario 4
Del escenario anteriormente descrito se puede concluir que:
1. MAICO provee a través de sus componentes solución a los requerimientos mínimos(definidas
en la Tabla 37) de la empresa descrita en este escenario.
2. Además proveer servicios para representar y modelar las comunidades según las preferencias
de sus miembros MAICO demuestra que a través de su módulo empresarial permite extender
los servicios grupales al contexto empresarial.
3. Este escenario de prueba también demuestra que los componentes compartidos si pueden
relacionarse con otros módulos diferente al de comunidad. En este caso los componentes
empresariales utilizaron a las políticas.
4.1.4. Escenario 5
A. Definición del Escenario
Representación una empresa grande con una amplia línea de negocios y sucursales que busca proyectar
su negocio a través de internet.
B. Ejemplo que describe el Escenario
Un almacén de cadena que posee varios puntos de venta en la ciudad está intentando proyectar su
negocio hacia el internet. Para ello tiene 3 objetivos primordiales:
1. Proyectar sus actividades a un negocio virtual según las necesidades de sus usuarios. Para esto,
le ofrecerá a cada uno de sus usuarios la posibilidad de configurar las preferencias que tienen
dentro del almacén especificados por los siguientes criterios:
o Que marca productos prefieren adquirir en el almacén.
o Por cada marca y producto seleccionado, cuanto estarían dispuestos a pagar por este y
bajo que contexto lo adquieren (ubicación, condición climática, fecha,etc.)
2. Con base en esa información, definir los parámetros de logística dentro del almacén: Recibo,
Almacenamiento, Distribución de productos a las diferentes ubicaciones.
3. Analizar los hábitos de los clientes del almacén para así poder agrupar a los usuarios por los
diferentes hábitos de compra que tengan. Con dichas agrupaciones, establecer comunidades
virtuales que le ofrezcan a sus usuarios información y ofertas según las características de los
hábitos detectados. Para cautivar más al cliente, se le permitirá a los usuarios interactuar con
los miembros de la comunidad a través de foros. La creación de esta comunidad tiene dos
propósitos: a) Cautivar al cliente mostrándole el interés que tiene el negocio por que los
usuarios participen en su evolución y b) Utilizar la información suministrada por los miembros
de la comunidad para establecer cambios en las actividades del almacén. Para poder utilizar la
información se le asignó el rol de administrador total a algunos funcionarios del almacén.
C. Componentes que se utilizan de MAICO
Figura 47. Componentes Utilizados en el Caso de Estudio 5
La Figura 40 muestra los componentes que se utilizan para modelar este caso de estudio. A continuación
se listan que requerimientos cumple cada uno de los componentes:
Información General: Definir el tipo y el sector de la empresa y de la comunidad que se desea
modelar.
Políticas: Establecer los permisos dentro de la comunidad y las características de las relaciones
entre la empresa y sus proveedores y la empresa y sus puntos de distribución.
Institucional: Como los puntos de venta pertenecen al almacén, la relación entre el almacén y
ellos se establece a partir del componente institucional.
Producto: Definir los productos que se ofrecen en el almacén.
Servicio: Definir las preferencias de marca/producto para cada uno de los usuarios.
Logística: Modelas las preferencias que tiene la empresa con respecto al recibo,
almacenamiento y distribución de sus productos en los diferentes puntos de venta. Estas
preferencias serán definidas por el almacén tras estudiar las preferencias de cada uno de sus
usuarios/cliente.
Roles: Diferenciar dentro de la comunidad la existencia de usuarios del almacén y empleados
del almacén.
Hábitos: Criterio básico para modelar las comunidades del almacén. Las comunidades son
generadas y agrupadas por los hábitos de compra de sus usuarios.
La tabla que se muestra a continuación (Tabla 38) muestra los criterios que son tomados en cuenta en el
Escenario 5, realizando una breve descripción que argumenta la toma en cuenta del criterio. Finalmente
en la última columna de la tabla se establecen que componentes proveen dicho criterio.
CRITERIO
Consideración del Perfil
Individual
Consideración de “Sub
Comunidades”
Tabla 38. Criterios tomados en cuenta dentro del Escenario 5.
DESCRIPCIÓN
COMPONENTE QUE LO PROVEE
Además de modelar los grupos, uno de los objetivos de este
escenario radica en cautivar y atraer la participación del
Componentes de MAIPU y comunicación
cliente. Para garantizar la participación de los clientes como
con ellos a través del componente de
usuarios de la comunidad se deben tener en cuenta las
hábitos.
preferencias de los usuarios al realizar los hábitos y las
características individuales de cada uno de ellos.
Dentro del almacén de cadena se deben establecer varios
Institucional
grupos de usuarios según sus hábitos de consumo. Debido a la
Clasificación por
Comportamiento
Consideración de medios
de distribución
Identificación de Roles
dentro de la comunidad
Aplicación en Negocios
Aplicación en la Web
gran variedad de usuarios que puede llegar a tener un
almacén de cadena, la probabilidad de que existan varios
hábitos de compra distintos es alta. Dichas hábitos de compra
serán modelados en grupos independientes que deben estar
relacionados con el almacén de cadena.
El modelo requerido por el almacén de cadena debe ser capaz
de generar y clasificar comunidades por los hábitos de sus
compradores.
A nivel empresarial se requiere definir medios y canales de
distribución para los productos del almacén de cadena. De
igual forma, las comunidades virtuales de los usuarios
requieren establecer mecanismos para la distribución de la
información (correo electrónico, correo físico, mensajes de
texto, entre otros)
Para que la empresa pueda extraer la información de los
usuarios de las comunidades, es necesario definir al menos un
rol administrativo conformado por el personal del almacén
que pueda acceder a toda la información que expongan los
usuarios a través de la comunidad y de su comportamiento
dentro de la misma.
La idea central del caso de estudio radica en la aplicación de
una estrategia de proyección del almacén de cadena a través
de un canal virtual mediante la toma en cuenta de la opinión
de los usuarios para enriquecer las actividades realizadas a
nivel interno de la compañía.
Para garantizar el éxito de las comunidades y su proyección a
un canal virtual, lo más conveniente es modelar dichas
comunidades en la web.
Hábitos y comunicación con MOCA para
generar comunidades a partir de hábitos
(ver Sección 2.3).
Políticas
Roles
Logística, Servicio, y Producto
Políticas y módulo de Comunidad
D. Forma de adquirir la información.
La adquisición de la información se realizará con los mecanismos descritos en la sección 2.2.3.1
asociados a cada uno de los componentes de MAICO que serán utilizados.
E. Aplicación del escenario a casos reales
El siguiente escenario puede aplicarse en:
1. Los almacenes de cadena existentes en Colombia que están proyectando sus negocios a través
de internet.
a. Carulla
b. Almacenes Éxito
F. Conclusiones del Escenario 5
Del escenario anteriormente descrito se puede concluir que:
1. MAICO provee a través de sus componentes, alternativas para hacer la proyección que plantea
el almacén de cadena (definidas en la Tabla 38).
2. El escenario muestra lo provechosa que resulta la interacción entre todos los módulos de
MAICO, al reflejar que además de poder utilizar MAICO en contextos comunitarios y
empresariales por separado (demostrados en los casos anteriores) permite la combinación y
uso de componentes tanto comunitarios como empresariales para generar mejores resultados.
5. CONCLUSIONES Y TRABAJO FUTURO
El modelo de adaptación de la información en comunidades MAICO es una interesante aproximación
que facilita el acceso y manejo de la información dentro de un grupo teniendo en cuenta las
características compartidas (modeladas a través de los hábitos, las preferencias sociales y las políticas)
de todos los miembros del grupo junto con las preferencias individuales que tiene cada uno de ellos (a
través de la interacción entre MAICO y MAIPU). Además garantiza la interacción de sus usuarios a
través del establecimiento de directrices de convivencia dentro del grupo así como los mecanismos
para validar y controlar dichas directrices a través de las normas.
Además, de servir para lo enunciado anteriormente, el módulo empresarial permite representar las
actividades de una empresa enfocándose en las preferencias que tiene dicha empresa para el manejo de
las actividades logística las ventas y el servicio al cliente de cada uno de los productos que se ofrecen.
Como se pudo apreciar en el quinto escenario de los casos de estudio (Ver Sección 4.1.4), la interacción
de todos los módulos de MAICO permite obtener resultados de mayor alcance que le permitirán a los
negocios relacionarse con sus clientes a través de comunidades virtuales generadas y clasificadas
teniendo en cuenta los hábitos de compra de sus usuarios.
A pesar de lograr tantos resultados, existen todavía algunas características que podrían (tomando como
base el trabajo ya realizado) ser incluidas dentro de este componente para ofrecer más servicios
orientados a las preferencias y necesidades de los grupos. Algunos de ellos son:
1. Automatizar el cumplimiento de las normas a través de la validación del cumplimento de
actividades.
2. Generar un sistema de recomendación de grupos para los usuarios de IAM. A través de este
sistema se utilizarían las preferencias de los usuarios con las cuales se revisaría si una
comunidad recién creada puede ser del interés de dicho usuarios. En caso de serlo, el sistema
le sugeriría al usuario vincularse a dicha comunidad a través de algún medio teniendo en
cuenta sus preferencias de despliegue.
3. En la cadena de valor genérica de Porter[13], existe algunas actividades y eslabones que no
fueron tomados en cuenta dentro del componente empresarial y que podrían enriquecer el
módulo empresarial y ampliarlo al uso de más negocios con diferentes características (negocios
orientados a prestar servicios, negocios que trabajan directamente con otros negocios y no con
clientes minoritarios, etc.)
6. REFERENCIAS
[1] Real Academia de la lengua española, “Diccionario Español Vigésima Edición”, 2008,
http://www.rae.es
[2] Kim, Yang Sok, Park, Sung Sik, Kang, Byeong Ho, and Choi, Young Ju, “Incremental Knowledge
Management of Web Community Groups on Web Portals”, LNCS, Vol 3336, Dec 2004, pp 198207.
[3] Pierrakos, D., Palilouras, G., Papatheodorou, C., Karkaletsis, V., and Diakaiakos Marios, “Web
Community Directories: A New Approach to Web Personalization”, EWMF 2003, LNAI 3209, pp.
113–129.
[4] Palilouras, G., Papatheodorou, C., Karkaletsis, V., and Spyropoulos, C.D., “Discovering user
communities on the Internet using unsupervised machine learning techniques”, Interacting
with Computers, Col 14, No 6, Dec 2002, pp 761-791.
[5] Baéz-Barranco, Jose, Stratulat, Tiberiu, Ferber, Jacques, “A unified Model for Physical and Social
Environments”, E4MASS, Vol 4389, 2007, pp 41-50.
[6] TImm, Ingo J., Scholz, Thorsten, Herzog, Otthein, Krempels, Karl Heinz, and Spaniol Otto, “From
Agents to Multiagent Systems”, International Handbook on Information Systems, Springer
Berlin Heidelberg, 2006, pp 35-51.
[7] Stathis, Kostas, Spence, Robert, de Brujin Oscar, and Purcell, Patrick, “Networked
Neighbourhoods”, Springerlink, 2006.
[8] Kannan, P. K., Chan, Ai-Mei, and Whinston, Andrew B., "Electronic Communities in E-Business:
Their Role and Issues", Kluwer Academic Publisher, Information System Frontiers, pp. 415 –
426, 2000
[9] Alencar, Paulo S. C., Cowan, Donald D., and Luo, Martin, "A Framework for Community
Information Systems", Kluwer Academic Publishers, Annals of Software Engineering, pp. 381 –
411, 2002
[10] Fink, Josef, Kobsay, Alfred, "A Review and Analysis of Commercial User Modeling Servers for
Personalization on the World Wide Web", Kluwer Academic Publisher, User Modeling and UserAdapted Interaction, pp. 209-249, 2000.
[11] Goy, Ana, Ardissono, Liliana, and Petrone, Giovanna, "Personalization in E-commerce
Applications", Spring-Verlag Berilng Heidelberg, 2007.
[12] Jameson, Anthony, and Smyth, Barry, "Recommendation to groups", Spring-Verlag Berilng
Heidelberg, pp 596-627 2007.
[13] Porter M., Ventaja Competitiva Creación y Sostenimiento de un desempeño superior, México,
Compañía Editorial Continental, S.A. De C.V., 1993
[14] Aoki, Kumiko. "Virtual Communities in Japan." Paper presented at the Pacific
Telecommunications Council Conference, 1994.
[15] Real Academia Española, “Apéndice 5: Lista de países y capitales, con sus gentilicios”, 2008,
http://buscon.rae.es/dpdI/apendices/apendice5.html.
[16] Higuera, María C., and Aragón, Fernando, “MOCA”, Módulo miembro de IAM. 2008.