INSTITUTO POLITÉCNICO NACIONAL -...
111
INSTITUTO POLITÉCNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN ANÁLISIS DE DECISIONES EN ESCENARIOS DECISORIOS EXPERIMENTALES T E S I S PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INFORMÁTICA PRESENTA: SERGIO VALDÉS VALDÉS DIRECTOR DE TESIS: DR. MAURICIO JORGE PROCEL MORENO MÉXICO, D.F. JULIO 2015
Transcript of INSTITUTO POLITÉCNICO NACIONAL -...
INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
ANÁLISIS DE DECISIONES EN ESCENARIOS DECISORIOS EXPERIMENTALES
T E S I S PARA OBTENER EL GRADO DE
MAESTRO EN CIENCIAS EN INFORMÁTICA
PRESENTA:
SERGIO VALDÉS VALDÉS
DIRECTOR DE TESIS:
DR. MAURICIO JORGE PROCEL MORENO
MÉXICO, D.F. JULIO 2015
SIP14
CESION DE DERECHOS
3
RESUMEN
El proceso decisorio es un tema extenso del cual se pueden realizar muchos trabajos de
investigación y no lo terminaríamos de cubrir completamente, existe infinidad de literatura donde
podemos encontrar desde el funcionamiento del cerebro humano, el proceso de la toma de
decisiones, hasta el desarrollo de algoritmos complejos que imitan el comportamiento de agentes
racionales. Nuestro trabajo se enfoca en el proceso de la toma de decisiones realizado bajo un
ambiente donde se puede medir el comportamiento de los agentes racionales involucrados en un
escenario decisorio, este es un tema extenso en el cual se puede profundizar para tratar de
descifrar los mecanismos mediante los cuales se lleva a cabo el proceso decisorio.
Enfocamos el desarrollo del presente trabajo en tratar de realizar una evaluación las decisiones
que son tomadas por sujetos “racionales”, cuales son los factores que pudiesen intervenir en este
proceso y como el escenario bajo el cual se presentan estos factores influyen en sujeto decisor.
Trataremos de abordar desde un enfoque práctico mediante el uso de las tecnologías de
información, como es que un ente racional toma decisiones bajo ciertos escenarios complejos,
estos escenarios pueden ser situaciones diarias u otras elaboradas, adaptadas y que permiten
observar el comportamiento de estos sujetos.
El objetivo final que pretendemos alcanzar con el resultado de este trabajo es poder cuantificar los
resultados de la experimentación que se pueda llevar a cabo sobre escenarios decisorios en donde
sea posible la parametrización de las diferentes variables involucradas que afectan el
comportamiento de los entes racionales así como los resultados que se obtengan al final de cada
uno de los experimentos que puedan realizarse.
En el desarrollo del trabajo se presentará el desarrollo de estructuras conceptuales, lógicas y
técnicas requeridas para el desarrollo de un sistema informático capaz de permitir realizar el
análisis del comportamiento de los agentes racionales a través de los resultados obtenidos para
diferentes escenarios modelados dentro del sistema, donde se verán reflejados los aspectos
conceptuales y lógicos propuestos inicialmente, también describiremos los progresos, las
dificultades, las soluciones implementadas y por último el desarrollo como un sistema informático
completo. Se describirá la funcionalidad desarrollada y se presentarán los resultados obtenidos
que nos permitirán realizar un análisis de los escenarios propuestos.
I
ABSTRACT
Decision making it’s a vast topic where many research work can be done, there is a lot of literature
about this topic, where we can find from human brain function, decision making even complex
algorithms that can imitate behavior of rational agents. This work focus on decision making under
an environment where behavior of involved rational agents can be measured. This is an extensive
topic where we can go deep trying to understand mechanisms that trigger this decision making
process.
This work focuses in trying to measure decisions taken by “rational agents”, which factors are
related to decision making process and how the scene where this factors appear influence to
rational agents involved. We’ll try to give a pragmatic approach using information technologies, to
try to find out how a rational agent make decisions on certain complex scenes. These scenes could
be daily situations or specifically adapted situations, where we be able to monitor agent’s
behavior.
Final goal that is to be achieved with result of this work is can measure results from made
experimentation on different decision scenes where we can parameterize different involved
variables that affects rational agent’s behavior and get results from these made experiments.
On this work we develop and introduce many conceptual structures, logical structures and
technical implementations required to develop an informatics system able to allow perform
analysis of rational agent’s behavior through obtained results for different modeled scenes inside
system, there we could find conceptual, logical and technical aspects proposed and introduced
during development of this work. Also we’ll describe progress, difficulties, and solutions
implemented to achieve final result as a full functional informatics system. We’ll describe
developed functionality and exhibit obtained results that will allow make analysis for the proposed
scenes.
II
CONTENIDO
RESUMEN ............................................................................................................................................. I
ABSTRACT ............................................................................................................................................ II
CONTENIDO ........................................................................................................................................ III
GLOSARIO ........................................................................................................................................... VI
ÍNDICE DE TABLAS ............................................................................................................................. VII
ÍNDICE DE FIGURAS ........................................................................................................................... VII
INTRODUCCIÓN ................................................................................................................................... 1
CAPÍTULO I EN QUE CONSISTE EL PROCESO DECISORIO ..................................................................... 3
1.1 Toma de decisiones ............................................................................................................... 4
1.2 Decisiones .............................................................................................................................. 6
1.3 Decisor ................................................................................................................................... 7
1.4 Criterios para la decisión ....................................................................................................... 8
1.5 Problema ............................................................................................................................... 8
1.6 Objetivos o metas.................................................................................................................. 9
1.7 Racionalidad ........................................................................................................................ 10
1.8 Razón ................................................................................................................................... 13
1.9 Evaluación de las Decisiones ............................................................................................... 14
CAPÍTULO II MODELO DE IMPLEMENTACIÓN ................................................................................... 16
2.1 Modelo General ...................................................................................................................... 17
III
2.1.1 Un primer acercamiento a un modelo general ................................................................ 17
2.1.2 Componentes de un escenario decisorio experimental .................................................. 19
2.1.3 Definición del requerimiento ........................................................................................... 25
2.2 Abstracción del modelo .......................................................................................................... 27
2.2.1 Modelo UML ..................................................................................................................... 28
CAPÍTULO III DESARROLLO ................................................................................................................ 39
3.1 Preparación de ambiente ........................................................................................................ 39
3.2 Instalación de ambiente .......................................................................................................... 40
3.3 Primer acercamiento ............................................................................................................... 40
3.3.1 Ultimátum o el dictador ................................................................................................... 41
3.3.2 Limitaciones tecnológicas ................................................................................................ 42
3.3.3 Implementación del modelo lógico Ultimátum o el dictador .......................................... 48
3.4 Generalización del modelo de implementación ..................................................................... 62
3.4.1 Almacenamiento .............................................................................................................. 63
3.4.2 Lógica ................................................................................................................................ 64
3.4.3 Presentación ..................................................................................................................... 65
3.4.4 Comunicación ................................................................................................................... 65
3.4.5 Resumen ........................................................................................................................... 66
CAPÍTULO IV RESULTADOS OBTENIDOS ............................................................................................ 69
4.1 Implementación del modelo general ...................................................................................... 69
IV
4.2 Integración .............................................................................................................................. 74
4.2.1 Módulo Experimentos ...................................................................................................... 74
4.2.2 Módulo Eventos ............................................................................................................... 75
4.2.3 Módulo Participar ............................................................................................................. 77
4.2.4 Módulo Análisis ................................................................................................................ 78
4.3 Escenarios decisorios experimentales .................................................................................... 79
4.3.1 Ultimátum o el dictador ................................................................................................... 80
4.3.2 El experimento del tranvía ............................................................................................... 81
4.3.3 El efecto del anclaje ......................................................................................................... 83
4.3.4 Los amantes de Catherine ................................................................................................ 86
4.3.5 La imagen borrosa ............................................................................................................ 87
4.4 Análisis de resultados .............................................................................................................. 89
4.5 Una mejora a la propuesta .................................................................................................. 90
CONCLUSIONES ................................................................................................................................. 92
ANEXOS ............................................................................................................................................. 95
Anexo I – Comparación de MVC contra MVVM ............................................................................ 95
Modelo Vista Controlador ......................................................................................................... 95
Modelo Vista - Vista Modelo ..................................................................................................... 95
REFERENCIAS ..................................................................................................................................... 97
V
GLOSARIO
AJAX
Asynchronous JavaScript And XML (Javascript
asíncrono con XML) ............................. 47, 58
AOP
Aspect Oriented Programation (Programación
Orientada a Aspectos) ............. 48, 49, 52, 96
BLOB
Binary Large Object (Objectos Binarios
Grandes) .................................................... 67
Framework
Hablando de sistemas informáticos, un
framework regularmente se refiere a un
cojunto de especificaciones, interfaces, y
herramientas que definen como un sistema
debe ser construido ............................. 45, 49
JSON
Java Script Object Notation (Notación de
Objetos de Java Script) .................. 61, 69, 76
LAN
Local Area Network (Red de Área Local) ........ 44
MIME
Multipurpose Internet Mail Extensions
(Extensiones Multiproposito de Correo de
Internet) .................................................... 46
MVC
Model View Controller (Modelo Vista
Controlador) .... 41, 50, 52, 53, 54, 58, 60, 64,
68, 96, 98
MVVM
Model View - View Model (Modelo Vista - Vista
Modelo) 60, 62, 63, 64, 67, 68, 70, 76, 96, 98
plugin
Complemento de una aplicacion que aporta
funcionalidad nueva y específica .............. 44
Spring
Framework opensource para la construcción
de aplicaciones Java ..... 41, 46, 50, 52, 95, 96
stakeholder
cualquier persona a quien le interesa alguna
actividad .................................................... 25
stakeholders.............................. Véase stakeholder
UML
Unified Model Language (Lenguaje Unificado
de Modelo)......................... 26, 28, 29, 37, 51
VI
ÍNDICE DE TABLAS
Tabla 1 - Ultimatum o el dictador ..................................................................................................... 42
Tabla 2 - Propuesta inicial de almacenamiento de la información ................................................... 47
Tabla 3 - Controles Vista Moderador ................................................................................................ 53
Tabla 4 - Controles Vista Participante ............................................................................................... 54
Tabla 5 - Respuestas actualizacion de estado Ultimatum ................................................................. 56
Tabla 6 - Funciones de comunicación cliente ................................................................................... 65
Tabla 7 - Funciones de comunicación servidor ................................................................................. 66
ÍNDICE DE FIGURAS
Figura 1 - Razón, Racionalidad, Razonabilidad .................................................................................. 10
Figura 2 - Bloques de la racionalidad práctica .................................................................................. 12
Figura 3 - Elementos principales de un escenario decisorio experimental ....................................... 17
Figura 4 – Elementos de un escenario decisorio experimental y su relación ................................... 19
Figura 5 - Diagrama de flujo general ................................................................................................. 22
Figura 6 - Flujo con agentes racionales ............................................................................................. 23
Figura 7 - Diagrama general del sistema ........................................................................................... 29
Figura 8 - Casos de uso Módulo Experimentos ................................................................................. 30
Figura 9 - Caso de uso Definir experimentos .................................................................................... 31
Figura 10 - Caso de uso Consultar experimentos .............................................................................. 31
VII
Figura 11 - Caso de uso Ajustar parámetros experimentos .............................................................. 32
Figura 12 - Casos de uso Módulo Eventos ........................................................................................ 32
Figura 13 - Caso de uso Crear evento................................................................................................ 33
Figura 14 - Casos de uso Módulo Análisis ......................................................................................... 33
Figura 15 - Caso de uso Obtener resultados ..................................................................................... 34
Figura 16 - Casos de uso Módulo Participar ...................................................................................... 35
Figura 17 - Caso de uso Participar en evento .................................................................................... 35
Figura 18 - Diagrama de clases UML ................................................................................................. 36
Figura 19 - Diagrama de secuencia del sistema ................................................................................ 37
Figura 20 - Secuencia de Evento Escenario decisorio experimental ................................................. 38
Figura 21 - Flujo de Ultimatum o el dictador .................................................................................... 49
Figura 22 - implementacion MVC Ultimatum ................................................................................... 51
Figura 23 - Implementación de comunicación Ultimatum ................................................................ 55
Figura 24 - Ajustes de implementacion MVVM ................................................................................ 59
Figura 25 - Modelo general de implementación MVVM ................................................................... 67
Figura 26 - Modelo solución general ................................................................................................. 70
Figura 27 - Módulo Experimentos ..................................................................................................... 75
Figura 28 - Módulo Eventos .............................................................................................................. 76
Figura 29 - Módulo Participar ........................................................................................................... 77
Figura 30 - Módulo de Análisis (Escenario Decisorio) ....................................................................... 78
VIII
Figura 31 - Módulo Análisis (Evento) ................................................................................................ 79
Figura 32 - Implementación de ultimatum ....................................................................................... 80
Figura 33 - Diagrama de flujo Experimento del tranvia .................................................................... 82
Figura 34 - Implementación experimento del tranvia ...................................................................... 83
Figura 35 - Diagrama de flujo Efecto del anclaje ............................................................................... 85
Figura 36 - Implementación Efecto del anclaje ................................................................................ 86
Figura 37 - Diagrama de flujo Amantes de Catherine ....................................................................... 87
Figura 38 - Implementación Amantes de Catherine ......................................................................... 87
Figura 39 - Diagrama de flujo Imagen Borrosa .................................................................................. 88
Figura 40 - Implementación Imagen borrosa .................................................................................... 89
Figura 41 - Propuesta de implementación de mejora....................................................................... 91
IX
INTRODUCCIÓN
Hablar del proceso decisorio implica un tema muy extenso el cual no terminaríamos de cubrir con
el desarrollo de un trabajo como este, existe mucha literatura al respecto en la que podemos
encontrar desde la comprensión del funcionamiento del cerebro humano hasta el desarrollo de
complejos algoritmos que pueden simular agentes racionales. La toma de decisiones como parte
del proceso es un foco de atención para estudios de diferente índole dentro del proceso decisorio,
todo esto resulta muy interesante y a la vez un mundo entero donde poder profundizar en los
mecanismos mediante los cuales se lleva a cabo el proceso decisorio.
El desarrollo del presente trabajo se enfoca en tratar de evaluar las decisiones que son tomadas
por sujetos “racionales” por qué lo hacen de ciertas maneras y cuáles son los factores que
pudiesen influir en la elección de tales decisiones. Trataremos de abordar desde un enfoque
práctico mediante el uso de las tecnologías de información, como es que un ente racional toma
decisiones bajo ciertos escenarios complejos, estos escenarios pueden ser situaciones diarias y
otras elaboradas, adaptadas y que permiten observar el comportamiento de estos sujetos.
Dicho en forma concreta el objetivo final que pretendemos alcanzar con el resultado de este
trabajo es poder cuantificar los resultados de la experimentación que se pueda llevar a cabo sobre
escenarios decisorios en donde sea posible la parametrización de las diferentes variables
involucradas que afectan el comportamiento de los entes racionales así como los resultados que
se obtengan al final de cada uno de los experimentos que puedan realizarse.
A pesar de darle un enfoque práctico al trabajo es necesario hacer algunas anotaciones respecto a
la terminología utilizada, por tal motivo en el primer capítulo daremos un breve recorrido por los
conceptos utilizados para abordar la teoría de decisiones, para tener una idea lo más clara posible
del uso los conceptos que manejaremos a lo largo del trabajo, ya que su uso cotidiano puede no
ser siempre con un sentido profundo o acertado de su significado real y sus implicaciones
ontológicas a las cuales haremos referencia, esto podría propiciar una discusión filosófica muy
amplia la cual no trataremos aquí, y en ningún momento afirmaremos o refutaremos la validez de
los conceptos ya que esto es una cuestión ajena al objetivo central de nuestro trabajo,
simplemente trataremos dejar en claro el significado de estos conceptos para entender mejor el
proceso decisorio.
1
Para poder plantear los escenarios que se tratarán, en el segundo capítulo, nos encargaremos de
hacer un recorrido por algunos de los diferentes tipos de experimentos que se han realizado para
estos estudios los cuales están probados y validados ampliamente, por tal motivo describiremos
algunos de ellos y propondremos como pudieran ser replanteados utilizando las tecnologías de
información, para darles un nuevo alcance, apegándonos lo más posible a su desarrollo original,
esto es siempre y cuando la naturaleza del escenario permita su implementación en un sistema
informático.
Para poder acercarnos al objetivo de poder plasmar diferentes escenarios decisorios como los
descritos en el capítulo dos, el tercer capítulo lo destinaremos a la abstracción de los conceptos
requeridos para poder implantarlos en un programa o sistema computacional que nos ayude a
recrear tales escenarios decisorios complejos usando la tecnología Java, así también haremos
mención de las limitantes tecnológicas que se pudieran presentar y las herramientas usadas.
Teniendo presentes y desarrolladas las estructuras conceptuales, lógicas y técnicas requeridas
para el desarrollo del programa final, se llevará a cabo el desarrollo de nuestro trabajo como un
sistema computacional, aquí se verán reflejados los aspectos iniciales, los progresos, las
dificultades, las soluciones implementadas y por último el desarrollo del sistema completo. Se
describirá la funcionalidad desarrollada y se verá el uso de esta herramienta para el análisis de los
escenarios decisorios complejos, esto es el punto central del presente trabajo.
Por último en cuarto capítulo, mostraremos la experimentación que puede ser realizada, como es
que se plantean los escenarios decisorios, de qué forma interactúan los sujetos con el
experimento y el ambiente, para finalmente llegar a la obtención de los resultados obtenidos de la
experimentación.
Al final presentaremos nuestras conclusiones donde detallaremos el alcance que se logró con los
objetivos planteados, daremos un resumen breve del sistema y el conocimiento adquirido que
hemos obtenido como parte del desarrollo de este trabajo.
2
CAPÍTULO I EN QUE CONSISTE EL PROCESO DECISORIO
El hombre desde siempre ha intentado tener un control sobre la realidad que lo rodea, para
modificarla para cuando no le resulta conveniente a sus propias finalidades. Esta voluntad para
influir tiene a hacerlo actuar con el fin de resolver problemas. En este proceso decisorio, la
decisión es el paso previo a la acción; Decidir no se trata simplemente de elegir, es más bien un
proceso continuo el cual involucra un verdadero y realmente complejo proceso de reflexión, el
cual se cree es racional y consciente, más adelante se cuestionará esta aseveración e igualmente
se analizará todo el proceso comprendido tanto en la toma de decisiones como el curso final de la
acción a tomar, para escenarios complejos, establecidos los cuales pueden involucrar a uno o
varios sujetos decisores que interactúan con el entorno decisorio y entre ellos.
Estudiar los procesos decisorios en individuos implica tener bien en claro que la decisión no es un
mero ejercicio intelectual, por el contrario, está concebida para la acción y evaluación de
alternativas lo cual concluye con una consecuencia obtenida de la decisión tomada.
Muchas investigaciones se han realizado acerca de este mundo de las decisiones y los procesos
involucrados con ello; las más variadas disciplinas han incursionado en él desde las matemáticas,
la lógica, la filosofía, la sociología, la psicología, por mencionar algunas. Los hombres tienen su
propia percepción del mundo y sus propias preferencias y aun dentro de un marco contextual que
les impone restricciones opinan, toman decisiones, resuelven problemas y definen su curso de
acción aplicando su propia racionalidad limitada, entre otras cosas por su propia singular visión de
la realidad la cual es simplemente la información disponible en ese momento.
La teoría de la elección racional es el aporte que desde el ángulo “psicológico administrativo”
como se usa a partir de Herbert Simon (Simon, 1960). Esta teoría de la elección racional, se interna
en lo que podemos dar en llamar el “meollo motivacional” que genera los procesos decisorios:
considera el rol de las motivaciones, con independencia de sus contenidos, en la formación de la
decisión humana. La teoría describe también las fases o etapas de aquéllos procesos, al tiempo
que brinda una amplia tipología decisoria completando el panorama descriptivo de nuestro tema.
Paralelamente, autores provenientes de la economía, la matemática, la estadística y otras
corrientes formales del pensamiento científico, van dando cuerpo a partir de John von Neumann y
Oskar Morgenstern a la teoría de la decisión (Von Neumann & Morgenstern, 1953). La teoría de la
decisión intenta ayudar al hombre a decidir; podríamos decir que es una metodología prescriptiva
3
o normativa que indica cómo se debe decidir para ser consecuente con los objetivos, preferencias,
y ciertos principios impuestos por el marco social y cultural que rodean al individuo decisor. Esta
afirmación puede resultar controversial, y se discutirá más adelante.
La teoría de la decisión se enfoca en particularidades de un sujeto al momento de tomar una
decisión porque, al prescribir tiene presentes las particulares preferencias, valoraciones, vivencias,
visión del mundo e información disponible para cada sujeto decisor. Estos elementos, constituyen
un dato incuestionable, más aún, una caja negra, de la cual solo podemos especular acerca de su
funcionamiento.
A continuación se presenta una breve descripción de aquellos conceptos que son de importancia
en el desarrollo del presente trabajo, y que ha sido formada a partir de diferentes fuentes.
Toma de decisiones
Las corrientes de pensamiento que existen para el estudio de la toma de decisiones son la
Normativa y la Descriptiva, la primera tiene como objetivo dictar las normas de como un individuo
debe decidir o actuar ante ciertas situaciones que se le puedan presentar, esto en sí mismo es una
tarea imposible e insostenible, ya que no se puede formular una ley universal que pueda
determinar los resultados obtenidos a partir de ciertas acciones tomadas, debido a que
inexorablemente existe un factor llamado incertidumbre o falta de información de todos los
factores que pueden afectar en la toma de una decisión.
Por otro lado el enfoque Descriptivo trata de describir el proceso de cómo se lleva a cabo la toma
de decisiones, esto es a través de un gran número de observaciones de diferentes individuos
sometidos a situaciones complejas en el cual el contexto es lo más semejante posible para cada
situación, este método no garantiza que los resultados obtenidos puedan ser aceptados como
válidos, simplemente trata de perseguir una descripción lo más aproximada posible a la manera en
la que se decide, cuando solo se le podría calificar como primeras aproximaciones. El enfoque
descriptivo es un enfoque puramente normativo operativo y no formal, en cuanto a su carencia de
modelos lógicos-matemáticos. Se compone de un conjunto de reglas empíricas basadas en el
sentido común que tienen por finalidad brindar alternativas para la solución de problemas.
4
De aquí en adelante tomaremos en cuenta el modelo Descriptivo como punto de referencia para
el estudio de los procesos que se pretende analizar; esto es debido a que realizar un análisis con el
enfoque Normativo es insostenible, no existe, no es posible realizar un estudio desde ese enfoque
dado que como se ha mencionado, aunque teóricamente todos los individuos deciden de manera
racional, en la práctica se observa que esto no es así y por tal motivo el enfoque Descriptivo nos
ayuda de una forma más aceptable a tratar de describir como el proceso decisorio se lleva a cabo
en cada individuo.
Casi toda actividad humana implica decisiones por lo tanto teorizar acerca de la teoría de
decisiones es casi como teorizar acerca de las actividades humanas, la teoría de decisiones se
enfoca en algunos aspectos de la actividad humana, pero en particular se enfoca en como usamos
nuestra libertad para tomar decisiones ya que estas no son decisiones tomadas al azar son
decisiones que están enfocadas a una meta. El proceso decisorio implica la facultad libre de
realizar una elección, requiere además llevar un control sobre la línea adoptada y un proceso
activo por parte del decisor.
La primera aproximación a un proceso de toma de decisiones fue realizado por Condorcet quien
presentó esta aproximación para la constitución francesa de 1793 (Hansson, 2005). Sin embargo el
punto de partida de las teorías modernas es considerado a partir de John Dewey quien dividió el
proceso en cinco fases (Dewey, 1978). Más tarde Herbert Simon modificó las cinco etapas
propuestas por Dewey para volverlas adecuadas a la toma de decisiones dentro de una
organización, de acuerdo con Simon el proceso consta de tres fases principales: “encontrar
ocasiones para tomar una decisión, encontrar posibles cursos de acción y elegir entre los
diferentes cursos de acción posibles”. Otra división influyente fue propuesta por Brim (Brim Orville
G., 1962) en él se divide el proceso en cinco pasos:
1. Identificación del problema
2. Obtención de la información necesaria
3. Producción de posibles soluciones
4. Evaluación de tales soluciones
5. Selección de una estrategia de desempeño
5
Muchos autores han criticado la idea que se tiene acerca de dividir el proceso en etapas
consecutivas, especialmente Witte (Witte, 1972), cuyo material empírico indica que esas etapas
son ejecutadas de forma paralela más que en secuencia.
La manera en la cual se pretende abordar los problemas que serán analizados tiene un enfoque
totalmente pragmático, debido a la propia naturaleza del problema a estudiar resulta imposible
poder dar o tratar de establecer una receta “mágica” que permita conocer el resultado de una
decisión.
Decisiones
Este es uno de los conceptos principales a estudiar y además cuenta con varias definiciones
estándar, a continuación citaremos algunas de ellas.
• Según el diccionario una decisión es una determinación o resolución que se toma de una
cosa dudosa. Etimológicamente decidir proviene del latín decidiere, cortar, resolver.
• La decisión es entonces un proceso de reflexión racional y consciente deliberado y
deliberativo que implica tiempo y esfuerzo. Lo anterior no es un simple ejercicio
intelectual y la evaluación de los resultados obtenidos es un proceso posterior al proceso
decisorio.
• Cuando tomamos decisiones o elegimos entre diferentes alternativas , tratamos de
obtener el un buen resultado posible, de acuerdo con los estándares de lo bueno y lo malo
• Decidir consiste en seleccionar una alternativa entre un conjunto de posibles alternativas.
Esta elección se encuentra a cargo de un determinado sujeto, en un determinado
momento y después de un proceso de reflexión.
Podemos definir a una decisión como el resultado de un análisis racional realizado ante una
situación compleja donde es necesario evaluar las condiciones y el contexto en el cual se
presentan estas condiciones para de esta forma tomar un rumbo de acción que permita llegar a
obtener un sujeto a la incertidumbre, que permita satisfacer las expectativas del sujeto decisor
con las consecuencias obtenidas en tomar tal curso de acción.
Casi todas las definiciones de decisión nos dicen que una decisión implica dos elementos
principales un escenario con recursos limitados y un conjunto de posibles caminos de acción a
tomar si no hay al menos dos cursos de acción, no hay decisión. Solamente hay decisión cuando:
6
se encuentran por lo menos dos posibles cursos de acción disponibles, existen por lo menos dos
resultados que poseen valores desiguales y cuando los diferentes cursos de acción tienen
diferente efectividad.
No se puede dar un criterio general de aceptación para el resultado obtenido con una decisión
motivo por el cual no podemos decir si una decisión es correcta o no, el sujeto decisor trata de
elegir un curso de acción que produzca un resultado deseado uno que sea eficaz respecto a lo que
él valora. Esto también es influido por que el contexto donde el individuo participa en el proceso,
no le permite estar seguro de qué es lo que quiere, esto lo determina más bien el grado de
satisfacción que pudiese llegar a producir el resultado obtenido.
Con la voluntad de influir en el resultado de un problema un individuo tiende a actuar para
solucionar tal problema, por tanto la decisión es el paso previo a la toma de una acción.
Decisor
Dentro del contexto de un problema decisorio, quien juega el rol de decisor, es aquel quien decide
en parte o en su totalidad, el camino de acción a seguir para la solución de un problema. En si
misma esta palabra no existe como un sustantivo lo más cercano que encontramos a ella es el
adjetivo “decisorio” que describe a aquellos individuos quienes cargan con la responsabilidad y
tienen la capacidad de tomar decisiones. Como acto humano la decisión implica la intencionalidad,
dicha voluntad del sujeto puede influir en el comportamiento del mundo para resolver problemas.
Por lo general es considerado como un elemento del problema se encarga de llevar a cabo el
proceso de análisis y toma de decisión de acuerdo a la información con la que cuenta en el
momento acerca de la situación en la que se encuentra, y sus propio juicio basado en
conocimiento adquirido anteriormente mediante su propia experiencia.
Una elemental clasificación de los factores que condicionan la personalidad del hombre los divide
en naturaleza y crianza. Todo lo que el hombre trae genéticamente podemos denominarlos
elementos genéticos o naturales. A lo largo de su vida, va incorporando a su personalidad una
serie de experiencias y aprendizajes que van condicionando, justamente con los factores naturales,
su personal visión del mundo que lo rodea; este segundo factor en la conformación de su
personalidad es su crianza.
7
Entendido esto, podemos comprender cómo cada sujeto, condicionado por sus aspectos naturales
y de crianza, comunes y distintos, tiene su propia y subjetiva visión del mundo que lo hace obrar
en consecuencia.
Sus preferencias, sus objetivos, la definición de las alternativas con que cree contar, la convicción
del nivel de incertidumbre en que cree encontrarse, la evaluación del abanico de resultados
previsible que cada curso reacción podrá ocasionar, son algunos de los elementos definidos por
aquélla particular visión del mundo que lo llevará a conducirse por la vida de determinadas formas.
Ante una situación concreta, los datos que recibe del contexto los percibe y decodifica. Luego su
mente los procesa para transformarlos en información para la decisión.
Su crianza y su genética condicionan esas percepciones y decodificaciones lo cual confirma que las
decisiones que se toman están influidas por el ambiente cultural que rodea al sujeto decisor, al
tiempo que su mente sólo puede procesar una porción de la masa de datos recibida. Visión del
mundo y capacidad de procesamiento restringida, son las dos limitaciones a la racionalidad,
definida ésta por Simon (Simon, 1960), con precisa claridad:
Criterios para la decisión
Los criterios a evaluar durante la toma de una decisión pueden ser de diferente índole, los
impuestos por el mismo problema, y los que se impone el sujeto decisor al momento de tomar
una decisión.
Problema
De forma similar al concepto de decisión encontramos que el concepto de problema tiene
diferentes definiciones estándar las cuales se presentan a continuación
• Obstáculo o inconveniente que impide o entorpece la realización o consecución de una
cosa.
• Cuestión difícil que se intenta resolver o explicar.
• Asunto delicado, difícil, que puede admitir varias soluciones.
8
En términos generales dentro de una situación, podemos describir un problema como un conjunto
de hechos o circunstancias las cuales dificultan la consecución de un fin, esto puede ser en un
asunto delicado o difícil, en el cual se pueden tener varias alternativas para tomar una solución.
Una de las mejores definiciones es de acuerdo con Russell L. Ackoff (Russell L, 1987) son cinco los
componentes que definen un problema:
1. Los sujetos decisores quienes pueden ser un grupo grande o pequeño o un solo individuo.
2. Los aspectos de la situación que se pueden controlar.
3. Los aspectos de la situación que no se pueden controlar.
4. Las restricciones que son impuestas.
5. Los resultados producidos por la combinación de selección y los elementos antes
mencionados.
Puede abordarse también este concepto dentro de un marco conceptual en el cual su enfoque
trata de plantear una situación, como un sistema en el cual se pretende poder predecir un
resultado a partir de una aproximación o deducción que se realiza partiendo de datos ya
conocidos. Durante el desarrollo de este trabajo, se plantea como problema la observación y el
análisis de los resultados recabados en diferentes escenarios para tratar de dar una aproximación
a posibles resultados partiendo de datos obtenidos mediante esta experimentación.
Se pretende dar a los problemas presentados en el desarrollo del presente trabajo una
tropicalización hacia ámbitos donde sea posible obtener variables cuantitativas que nos permitan
obtener información confiable a lo largo del desarrollo de los experimentos y el trabajo.
Objetivos o metas
En el contexto de un problema se les puede conceptualizar como elementos, materiales o no
materiales respecto a los cuales el decisor propone un nivel de aspiración, el cual es dado
subjetivamente dependiendo del individuo esto puede responder a una formula o expresión de
deseos de acuerdo a la consecución, dicho de otra forma toda acción tomada en un proceso de
decisión responden a una motivación.
9
Los objetivos pueden restructurar las escalas relativas de valores que los individuos establecen en
la búsqueda de diferentes metas. En el nivel más alto se ubican los que se consideran, más
significativos mientras que en los niveles sucesivos encontraremos los más bajos.
Racionalidad
Se le puede definir como una característica propia de un ser racional la cual le permite pensar,
evaluar y actuar de manera tal que las acciones que sean tomadas permitan obtener el mayor
grado de satisfacción posible. Pareciera que de algún modo está relacionada con la cordura pero
esto nos lleva a cuestionar lo poco que sabemos de ella y la conclusión a la que se llega es que no
sabemos cómo funciona.
Figura 1 - Razón, Racionalidad, Razonabilidad
Fuente: diseño propio
Depende de otros factores que permiten su existencia, el primero que es la característica que
define a un ser como racional, esta es la “Razón” que es atribuida exclusivamente a los humanos y
permite definirles como “seres racionales”, posteriormente tenemos la “Razonabilidad” que es
aquella cualidad de “razonable” que puede tener la racionalidad, de esta forma llegamos a la
racionalidad, que podemos interpretar como el ejercicio de la facultad llamada “Razón”.
Se es racional cuando se seleccionan los medios apropiados para alcanzar los fines que se han
señalado. Se hace necesario emplear el término “racional” justamente con los adverbios
apropiados. Entonces puede llamarse objetivamente racional a una decisión sí en realidad el
comportamiento correcto para maximizar unos valores en una situación dada. Es subjetivamente
10
racional sí maximiza la consecuencia relativa al conocimiento real del sujeto. Es conscientemente
racional en la medida en que el ajuste de los medios a los fines sea un proceso consciente. Es
deliberadamente racional en la medida que el ajuste de los medios a los fines haya sido realizado
deliberadamente. Una decisión es organizativamente racional se reorienta a las finalidades de la
organización; es personalmente racional si se orienta hacia las finalidades del individuo. Es
imposible que el particular comportamiento de un individuo sólo y aislado alcance un alto grado
de racionalidad. Es tan grande el número de alternativas que necesita explorar y tan vasta la
información que tendrá que valorar que resulta difícil concebir siquiera una aproximación a la
racionalidad objetiva. La elección individual tiene lugar en un medio ambiente de “supuestos” o
premisas que el sujeto acepta como base de su elección; el comportamiento resulta aceptable
únicamente dentro de los límites establecidos por estos “supuestos”. El comportamiento real no
alcanza la racionalidad objetiva, por lo menos de tres maneras:
1. La racionalidad exige un conocimiento y una anticipación completa de las consecuencias
que seguirán a cada elección. En realidad, el conocimiento de las consecuencias es
fragmentario.
2. Dado que estas consecuencias pertenecen al futuro, la imaginación debe suplir la falta de
experiencia al asignarles valores; pero sólo es posible anticipar de manera imperfecta esos
valores.
3. La racionalidad exige una elección entre todos los posibles comportamientos alternativos.
En el momento previo a la decisión, sólo se nos ocurren unas pocas de esas posibles
alternativas.
Por los motivos expresados anteriormente podemos afirmar que para un decisor dado la
racionalidad objetiva no existe.
Racionalidad teorética
Este tipo de racionalidad destaca la propiedad que tiene la susodicha razón para conocer la
realidad, además que se enfatiza el uso de esta racionalidad como un instrumento de
conocimiento, ya que nos permite expresar las causas, y principios mediante términos generales a
los que se les define como reglas lo cual es la base o principio para la formalización de los
conocimientos.
11
Racionalidad práctica
A diferencia de la racionalidad teorética, la racionalidad práctica se usa con el fin de describir el
uso que tiene la razón para orientar y dirigir acciones. Se puede apreciar su uso práctico al definir
al ser humano como un ser racional; esta racionalidad nos indica o trata de explicar que existe una
asociación directa pensar, ser y actuar, lo cual podemos entender como “La posibilidad de dar
cuenta reflexiva de las actividades que resultan determinantes para la significatividad de lo
humano”.
Figura 2 - Bloques de la racionalidad práctica
Fuente: diseño propio
La responsabilidad y libertad dependen de las actividades significativas, ya que implican el
resultado de la capacidad del hombre para actuar, además que se debe añadir un aspecto externo
el cual es la dimensión de la obra, lo que le otorga un significado a tal acción.
Por tal motivo la pérdida de la racionalidad seria por tanto la pérdida de la humanidad, lo que
implicaría desprecio por las acciones significativas, lo cual se ve transformado en una degradación
de la acción racional a favor de acciones salidas de emociones irracionales.
Con tales antecedentes a partir de los años 70’s del siglo pasado asistimos a una rehabilitación de
la filosofía práctica como modelo filosófico de la racionalidad, fundamentalmente por dos
motivos:
• La crítica al modelo científico como garantía de validez de nuestros conocimientos y a su
idea de la neutralidad.
12
• La consideración de la reunión entre pensar y hacer como un ejercicio práctico de la razón
puesta de relieve en las diversas actividades de los hombres consideradas como prácticas
sociales.
El auge de las tecnologías y la primacía que va adquiriendo la aplicación de los conocimientos
como determinante de su valor, son otros tantos factores de fondo que permiten entender el
auge de la racionalidad práctica y la inversión que se produce respecto a la consideración
clásica de la preponderancia de la razón teorética. Hoy el discurso de la razón tiene un sesgo
práctico en el que ha de inscribirse el momento teorético como el momento segundo no el
momento secundario de una reflexión filosófica.
Podemos por tanto entender la racionalidad como la posibilidad que tiene un agente de poder
dar ‘cuenta reflexiva’ de las actividades que resultan determinantes para la significatividad de
lo humano.
Razón
La “razón” parece ser un mecanismo que utilizamos al momento de realizar una decisión en un
escenario complejo, donde es necesario obtener información que nos permita evaluar de manera
“racional” el posible resultado esperado a partir de la toma de una acción u otra que sea posible
realizar.
Podemos además clasificar a la racionalidad en dos: “Racionalidad Teorética”, este tipo de
racionalidad destaca la propiedad que tiene la razón para poder conocer la realidad, permite ser
usada además como un instrumento de conocimiento gracias a su énfasis que realiza en la
formalización de conocimientos. Por otra parte tenemos la “Racionalidad Práctica” que
principalmente se encarga de orientar y dirigir acciones, ya que indica como existe esa singular
circularidad entre pensar – ser – actuar, motivo por el cual el uso práctico que se le da es el de
definir al ser humano como racional.
Para poder darnos una idea de cómo se define la realidad que comúnmente aceptamos, podemos
abstraer esta realidad de manera que tengamos un contexto de referencia para cierto problema,
donde conozcamos las variables involucradas y como estas forman parte del problema a resolver
mediante el proceso “racional” de toma de decisiones. El propósito de formar un contexto para el
planteamiento de un escenario de toma de decisiones es, simplificar el entorno que será
13
observado dentro de los experimentos que posteriormente serán planteados más adelante en el
desarrollo de este trabajo.
Dentro de un contexto cierta decisión puede parecer acertada o no dependiendo del grado de
satisfacción que obtiene una persona al realizar una acción entre varias disponibles, esta
satisfacción puede ser obtenida por la decisión o por el resultado obtenido de la elección realizada,
el problema que esto representa consiste en que poder realizar la medición de ese grado de
satisfacción lo cual ya es un reto bastante complejo.
El panorama con el que nos encontramos al iniciar el estudio acerca de la manera en la cual los
seres humanos tomamos decisiones, tiene una premisa fundamental. La cual es que, los seres
humanos tenemos la facultad para hacer pleno ejercicio de esa cualidad llamada “razón”.
Evaluación de las Decisiones
Poder realizar la evaluación de las decisiones se consigue mediante una asignación de números a
los objetos o hechos que implican las decisiones, lo cual nos permitirá llevar a cabo mediciones
sobre los aspectos relevantes de este proceso decisorio, es decir el proceso de cuantificar la
experiencia de dicho mundo. Por medio de la cuantificación asignamos un valor a una variable
para un suceso o muestra determinado. Estableciendo escalas numéricas que nos permitan
realizar mediciones podemos utilizar herramientas matemáticas para el tratamiento y análisis de
los resultados obtenidos.
La variedad de los conceptos pueden definirse en tres grandes clases:
• Clasificatorios: provienen del lenguaje ordinario
• Cuantitativos: implican la medición de magnitudes.
• Comparativos: Son un tipo intermedio
Para poder realizar mediciones sobre el proceso decisorio necesitamos:
• Un instrumento o herramienta de medición
• Una escala de medición sobre las variables que están involucradas en el proceso decisorio
• Un procedimiento o función para realizar las mediciones
14
Una vez que se hayan definido estos puntos para el proceso de la toma de decisiones podremos
cuantificar los datos obtenidos y podremos realizar comparaciones desde un punto de vista
descriptivo de la toma de decisiones por tanto podremos realizar comparaciones entre
comportamientos y situaciones similares.
15
CAPÍTULO II MODELO DE IMPLEMENTACIÓN
En el capítulo anterior describimos brevemente y de manera conceptual el proceso decisorio, de
forma que nos hemos familiarizado un poco con los términos que estaremos utilizando a lo largo
del desarrollo del presente trabajo.
Después de esta explicación breve que hemos presentado en el capítulo anterior, el presente
capitulo lo dedicaremos a describir el modelo mediante el cual nos apoyaremos para el desarrollo
técnico del sistema que pretendemos desarrollar.
Para comenzar con el desarrollo de nuestro modelo daremos la definición propia del aspecto
principal con el cual estaremos trabajando, el cual es un escenario decisorio experimental, dicho lo
anterior proponemos la siguiente definición de escenario decisorio experimental:
“Un escenario decisorio experimental es una situación que tiene reglas, en la cual pueden
participar uno o más individuos quienes deberán analizar las opciones que tienen disponibles para
tomar una decisión que les permita obtener un resultado o beneficio, esperando obtener el
máximo provecho de la elección que han tomado”.
En este punto es donde nuestro trabajo entra en juego ya que para llevar a cabo el análisis del
comportamiento de los individuos en el proceso decisorio llevaremos a cabo las siguientes
actividades: primero, plantearemos el modelado para poder representar un escenario decisorio
experimental, describiremos sus componentes procurando detallar los parámetros, con el fin de
poder realizar su implementación en un sistema informático.
Procuraremos hacer énfasis en aquellos parámetros que resulten de importancia para el proceso
decisorio y que nos permitan realizar una cuantificación de sus variaciones, es allí de donde
obtendremos los resultados y podremos realizar un análisis posterior a los experimentos
realizados. Esperamos que la información obtenida mediante dicha experimentación permita un
mejor entendimiento del comportamiento de los individuos racionales que participan en estos
escenarios decisorios y a su vez del comportamiento global del escenario visto como un sistema.
16
Modelo General
Un primer acercamiento a un modelo general
Como nos podremos imaginar de primera instancia, un escenario decisorio experimental puede
involucrar diferentes variables, de diferentes características y diferente naturaleza, de todas ellas
nos limitaremos a aquellas que resulten de importancia y además puedan ser cuantificadas y
controladas como parte de las características de un escenario decisorio experimental. Esta es la
razón de hablar de un modelo general resultaría extremadamente complejo generar un modelo
que se adapte a cualquier escenario que pudiese existir esto sería una tarea en extremo compleja,
por tal motivo para el diseño de nuestro modelo general procuraremos que el modelo pueda
adaptarse a cualquier escenario que se desee implementar.
Bien puede ser que algún escenario requiera dar seguimiento a una cantidad de dinero, a la
obtención de algún beneficio, a tiempo como espera o rapidez e incluso satisfacción emocional o
sentimientos de culpabilidad con respecto a una decisión que pudo haber tenido consecuencias
catastróficas.
De acuerdo a la descripción mencionada anteriormente la propuesta que realizamos para la
implementación de un modelo de un escenario decisorio experimental se presentará en la
siguiente figura.
Figura 3 - Elementos principales de un escenario decisorio experimental
17
Fuente: diseño propio
En la Figura 3, tenemos de forma general la conceptualización que proponemos, teniendo como
componentes del escenario decisorio experimental:
• Participantes
• Elementos
• Propiedades
• Interacción
• Objetivos
A grandes rasgos:
Participantes: Aquellos individuos que estarán participando en el escenario, son quienes deberán
tomar las decisiones dentro del escenario, activarán las condiciones que cambien las
circunstancias de los escenarios y se apegarán a las reglas que sean especificadas para el escenario
decisorio experimental.
Elementos: Son los componentes del escenario que no cambian y por tanto no son relevantes para
el análisis deseado, estos pudieran convertirse en propiedades siempre y cuando fuera requerido
para el análisis del escenario decisorio experimental, aquí podríamos hablar de variables como el
color o el tamaño del texto, la fecha del año, la temperatura del recinto donde se encuentran los
participantes, el número de calzado de los participantes, etc. Con la lista anterior solamente
pretendemos aclarar que pudieran ser elementos que se definen para el escenario pero que no
son relevantes al momento de llevar a cabo el análisis sobre las variables a las que se quiere dar
seguimiento.
Propiedades: Estos son componentes del escenario que pueden cambiar por el comportamiento y
la toma de decisiones de los participantes, básicamente son elementos que tienen importancia
porque son relevantes para los resultados obtenidos, se definen como parte del escenario
decisorio experimental y serán las que se tengan en cuenta al momento de los análisis de
resultados de la experimentación que se lleve a cabo. Aquí bien podemos hablar de dinero,
cantidad de un objeto o bien, un grado de satisfacción, o bien un grado de culpa que se pueda
obtener por una decisión, esto que es sólo por mencionar algunas posibilidades para estas
propiedades.
18
Interacción: Es un componente lógico del escenario, define las interacciones y reglas que existen, a
las cuales están sujetos los participantes, los elementos y las propiedades, producirán estados
intermedios entre el inicio del escenario y el fin del escenario además que permitirán llegar a
estados en los cuales se dará por finalizado un escenario decisorio experimental.
Objetivos: Es una parte de la definición lógica del escenario consiste en la meta la cual se debe
llegar para poder dar por finalizado el escenario, también podemos decir que son los estados
finales del escenario donde no será posible continuar con la interacción de los participantes.
Poniendo lo anterior en un primer esquema conceptual donde además indicaremos de forma
gráfica la relación existente tenemos:
Figura 4 – Elementos de un escenario decisorio experimental y su relación
Fuente: diseño propio
Componentes de un escenario decisorio experimental
A continuación se detallarán los elementos que de acuerdo a nuestra propuesta, de esta forma
acercarnos al modelo inicial que plantearemos para el desarrollo de un sistema informático.
19
Participantes
Como ya se mencionó anteriormente, este componente es fundamental para el escenario, son la
fuente de los aspectos que buscamos comprender, los cuales son las decisiones.
Son agentes que se supone son racionales quienes se encargarán de llevar el control de lo que
ocurre dentro del escenario, guiaran su comportamiento de acuerdo a las reglas de interacción y
para el fin de nuestro trabajo son humanos.
Elementos
Estos elementos no tienen relevancia para el análisis de los resultados que sean obtenidos de la
experimentación, pero es necesario tenerlos en cuenta porque forman parte de la definición del
escenario y es posible que puedan convertirse en propiedades en dado caso que se requiera
analizar si influyen de manera directa sobre él como los participantes toman las decisiones dentro
del escenario.
Propiedades
Estas características intrínsecas del escenario, puede ser que representen dinero, movimientos,
fichas, palabras, adjetivos, etc. Un escenario está compuesto generalmente por varias de ellas,
aquí ponemos especial atención ya que estas propiedades podrán formar parte del conjunto de
variables que se desee contemplar como parte del análisis de un conjunto de resultados obtenidos
por la experimentación, esto es para poder dar explicación a los resultados obtenidos.
Interacción
Definimos de manera general la interacción, como aquella parte del escenario que engloba la
lógica, las reglas que existen, y los medios que tienen los participantes para intercambiar
información con el escenario. Este punto es de suma importancia en el desarrollo del modelo de
nuestro trabajo esto se explica de forma breve a continuación y se detallará posteriormente.
Todas las interacciones que se lleven a cabo en el escenario estarán definidas desde el inicio, por
lo tanto forman parte de la estructuras fundamentales del escenario y aunque puedan tener
variaciones será difícil que tales cambios o modificaciones a la interacción se lleven a cabo dentro
20
del mismo escenario, por lo tanto y de manera inicial estas no podrán ser alteradas, pero será
posible que existan o que se puedan definir diferentes escenarios con reglas similares.
Objetivos
Definiendo de forma global este elemento de los escenarios decisorios, resulta complejo de cierta
forma, debido a que la definición que propongamos tendría que abarcar un gran número de
posibilidades para diferentes escenarios experimentales que puedan presentarse, ya sea obtener
una ganancia, resolver un problema, obtener algún tipo de beneficio o ventaja, o bien sentirse
libre de una responsabilidad moral que implique un sentimiento de culpa.
Tratar de generar una definición la cual satisfaga todos los posibles casos que puedan darse en un
escenario decisorio experimental simplemente no es posible por lo tanto, dejaremos la definición
de estos objetivos como:
Un estado final el cual se pretende alcanzar dentro de un escenario decisorio experimental y que
sirve como referencia para poder decir que un escenario experimental ha finalizado.
Relación entre los elementos del escenario decisorio experimental
Ya hemos presentado nuestra definición de los componentes que consideramos necesarios para el
modelo de los escenarios decisorios, pero ¿Que hay acerca de la forma en cómo se relacionan
estos elementos?
A continuación describiremos la manera en que estos elementos tienen relación dentro de un
escenario decisorio experimental para así obtener una un modelo global que permita llevar a cabo
el desarrollo de un escenario decisorio experimental a un sistema informático.
En la Figura 4, plasmamos de manera significativa la relación que existe entre los elementos del
escenario decisorio experimental, que proponemos para el desarrollo de este trabajo, a
continuación lo enunciaremos:
En un escenario decisorio experimental los participantes interactúan con las propiedades a través
de las reglas de interacción, estas reglas de interacción definen el comportamiento de las
propiedades en el escenario y de las acciones que pueden tomar los participantes en la interacción
con el escenario. Las reglas de interacción además, definen objetivos los cuales indican estados
21
finales en los que el escenario puede darse por terminado, los participantes tratarán de alcanzar
los objetivos haciendo uso de los mecanismos disponibles para la interacción con las propiedades
a través de las reglas de interacción.
De la descripción anterior podemos desprender una regla general del comportamiento de un
escenario decisorio experimental como: un conjunto de estados que pueden ser definidos a través
de los valores de las propiedades, teniendo incondicionalmente un estado inicial, varios estados
intermedios y uno o varios estados finales donde los objetivos han sido alcanzados.
Hasta hace un momento nos limitamos a hacer mención de los componentes de una forma
general y totalmente conceptual, en el párrafo anterior mencionamos un punto clave nos ayudará
a llevar la transición desde el modelo conceptual hacia un modelo abstracto que podamos replicar,
esto por la razón que detectamos que los escenarios decisorios pueden ser representados
haciendo uso de un diagrama de estados, ya que podemos observar que estos siempre tendrán un
estado inicial, uno o más estados intermedios y uno o más estados finales.
Figura 5 - Diagrama de flujo general
Fuente: diseño propio
Nos limitamos a definir de forma general los elementos, sus interacciones y su flujo, debido a las
variaciones que puede existir para diferentes escenarios decisorios, estamos conscientes que
pueden existir diferentes flujos que no siempre seguirán el mismo orden para diferentes
22
escenarios, por lo tanto no es posible que podamos cubrir cada uno de estos para cada escenario
decisorio experimental, por lo tanto en nuestro trabajo consideraremos solamente aquellos
estados que sean relevantes para el análisis de las decisiones que se llevan a cabo, estas
definiciones se harán para cada uno de los escenarios específicos que sean modelados.
En la Figura 5, hemos plasmado el primer diagrama de flujo que representa un escenario decisorio
experimental, aunque parezca muy sencillo en realidad es un diagrama general con el cual
pretendemos plasmar que los escenarios decisorios experimentales que modelaremos, se
adaptarán a este diagrama de flujo. Y ahora ¿Dónde quiera nuestro agente racional? En la Figura 6
completamos el diagrama anterior introduciendo el agente racional (antes mencionado como
participante) como parte activa del proceso llevado a cabo en el escenario decisorio experimental.
Figura 6 - Flujo con agentes racionales
Fuente: diseño propio
La figura anterior plantea el flujo en relación a cómo se pueden llevar a cabo para una interacción
en un escenario decisorio experimental donde los agentes racionales dictan el comportamiento
del flujo a través de las decisiones que toman. Por ejemplo, sí tenemos un escenario decisorio
23
experimental con tres estados A, B y C, como en el ejemplo de la figura, es posible que las
decisiones que tomen los agentes racionales nos lleven de un estado a otro hasta que se cumpla
una condición que indique el final del escenario decisorio experimental, a esto le llamaremos una
iteración del escenario decisorio experimental.
En la Figura 6, ya observamos de forma directa la interacción que tienen los agentes “racionales”
con el flujo que se llevó a cabo en un escenario decisorio experimental, es importante hacer notar
un punto de suma importancia que se introduce en esta figura, estas son las decisiones que toman
los agentes racionales y son ellas las que modifican a través de las reglas de interacción el estado
del escenario decisorio experimental.
Llevar los conceptos a un programa de software
En las definiciones anteriores hemos presentado las definiciones que proponemos para un
escenario decisorio experimental hemos visto de forma global sus componentes y las relaciones
que existen entre ellos basándonos en lo anterior encontramos posible que estos conceptos sean
llevados al terreno de la informática de la siguiente manera:
Proponemos que el escenario decisorio experimental sea modelado como un programa o sistema
informático en el cual representaremos los elementos y propiedades del escenario decisorio
experimental como variables de entorno del programa, las reglas de interacción del escenario
decisorio experimental serán trasladadas a reglas lógicas que pueden ser implementadas en un
algoritmo de software, estas reglas o condiciones o propiamente dicho el programa definirá los
estados inicial, intermedios y final (objetivos) para el escenario decisorio experimental y también
las condiciones que definirán las transiciones entre los diferentes estados. Por último los agentes
racionales que tomarán decisiones en el escenario decisorio experimental serán los usuarios del
programa informático.
En el párrafo anterior definimos como pretendemos llevar esta idea a un programa informático,
esto es sólo una definición conceptual llevada desde la propuesta de escenario decisorio
experimental hacia la implementación como un sistema informático, aunque esta definición no es
suficiente para poderlo llevar a cabo, nos orienta para poder enfocar los esfuerzos en el diseño y
construcción del sistema.
24
¿Qué sigue ahora?
Hasta el momento nos hemos centrado en dejar claro el concepto que hemos desarrollado como
propuesta para la implementación de un escenario decisorio experimental, como un programa
informático, ahora lo que haremos es plantear una definición formal del requerimiento para llevar
a cabo esta tarea.
Para la definición de nuestro requerimiento haremos uso de varias herramientas de diseño que
usamos en el desarrollo de un sistema informático, esto lo veremos a detalle en lo que resta del
presente capítulo.
Definición del requerimiento
Inicialmente pensamos en generar un requerimiento para este proyecto de software, como si se
tratase de un proyecto solicitado por un interesado o stakeholder, pero a ser este proyecto una
propuesta y no un requerimiento específico preferimos no generar una definición de un
requerimiento formal, en lugar de esto enunciaremos una propuesta de software que sea
funcional nos permita llevar a cabo esta experimentación con escenarios decisorios que pueden
ser descritos por muestra modelo general que hemos propuesto, de tal forma que a continuación
presentamos el enunciado de nuestra propuesta.
Propuesta del proyecto
Crearemos un sistema informático que tenga las siguientes características y funcionalidades:
• Será una aplicación web
• Permitirá realizar experimentación con escenarios decisorios experimentales
• Permitirá definir diferentes escenarios decisorios experimentales
• Permitirá parametrizar los valores de inicio de los escenarios decisorios experimentales
• Será posible crear diferentes instancias de los escenarios decisorios experimentales
• Permitirá la interacción de diferentes clientes con los escenarios decisorios
experimentales desdé diferentes terminales
• Permitirá a los diferentes clientes o participantes conectarse a las instancias de
experimentos creadas
• Llevará un registro del comportamiento de la experimentación
25
• Permitirá almacenar la información de los escenarios decisorios experimentales en una
base de datos
• Almacenar a la información de resultados en una base de datos
• Permitirá explotar la información obtenida posteriormente
En los puntos anteriores planteamos a groso modo, las características que tendrá nuestra
aplicación estos los podemos tomar como requerimientos funcionales para posteriormente
plasmarlos en el modelado de nuestro proyecto como un sistema informático y no solamente el
modelado de un escenario decisorio experimental, esto lo haremos más adelante utilizando UML.
Los puntos que se han establecido como puesta para el desarrollo de nuestra aplicación pueden
ser cubiertos con los siguientes módulos que consideramos pueden satisfacer las necesidades que
surgen de los puntos mencionados, los módulos que propondremos son los siguientes:
• Módulo de Experimentos
• Módulo de Eventos
• Módulo de Análisis
• Módulo de Participación
A continuación presentamos una breve explicación del funcionamiento de cada uno de los
módulos que proponemos como parte del sistema, esto nos servirá como base para el modelado
de los casos de uso del sistema.
Módulo de experimentos
Este módulo permitirá al experimentador administrar los diferentes escenarios decisorios
experimentales que se encuentran disponibles en el sistema, aquí se podrá verificar la información
de los escenarios decisorios, se pretende además que este módulo se pueda crear nuevos
experimentos para ser agregados como parte del sistema.
Módulo de eventos
Este módulo se podrán crear eventos de los diferentes escenarios decisorios experimentales, aquí
tenemos que dejar claro que un experimento y un evento no son la misma cosa, el experimento o
escenario decisorio experimental, define el comportamiento, el modelo, las reglas a seguir, y los
participantes que conforman un escenario decisorio experimental, podemos decir simplemente
26
que son la definición de los experimentos, mientras que un evento será una instancia de un
experimento esto es cada vez que se lleve a cabo un experimento será por qué se ha creado un
evento del experimento, el cual tendrá un ciclo de vida.
Módulo de análisis
Este módulo permitirá obtener los resultados de los experimentos que hayan sido realizados en el
sistema, será aquí donde se podrán observar gráficas que describan el comportamiento de las
propiedades de los escenarios decisorios experimentales de acuerdo a la definición de tales
parámetros como propiedades de los escenarios decisorios experimentales.
Módulo de participación
Este módulo permitirá llevar a cabo la experimentación con los escenarios decisorios
experimentales disponibles en el sistema, aquí se podrán observar los eventos que se encuentran
disponibles para que un participante pueda unirse, y posteriormente presente el escenario
decisorio experimental de forma que el participante pueda interactuar con el escenario y en caso
de ser necesario con otros participantes del evento, todo esto apegándose a las reglas de
interacción del escenario decisorio experimental.
Abstracción del modelo
Hasta ahora solo hemos mencionado el “Escenario decisorio experimental”, y lo hemos definido
en un nivel conceptual, donde simplemente escindimos los componentes, con lo anterior
pretendemos dar un primer acercamiento al enfoque que hemos adoptado para poder llevar
nuestro modelo a un sistema informático, hasta este momento hemos definido las piezas, pero
aún debemos definir la manera en la cual uniremos estas piezas para lograr el objetivo buscado, lo
que es un camino largo por recorrer para poder llevar a cabo la implementación en un sistema
informático.
A partir de ahora llevaremos nuestro modelo conceptual definido anteriormente, a un modelo
abstracto, donde podamos realizar el análisis de sus partes para su posterior implementación.
Como bien sabemos para el desarrollo de un sistema informático, existen diversas metodologías
establecidas, es nuestro caso resultó complicado poder establecer alguna, por tal motivo y
teniendo en cuenta experiencia anterior en desarrollo de proyectos, sabemos que siempre el
27
primer paso que consiste en la definición (el presente capítulo), y nos encontramos con los
siguientes obstáculos:
• Es un tema que no ha tenido mucho impulso en el área de la informática.
• No hemos realizado un proyecto de esta naturaleza anteriormente.
• No tenemos experiencia en la realización de lo descrito sin ayuda de un sistema
informático.
• No tenemos definición directa de un requerimiento por parte de un grupo de interesados
o “stakeholders”, para esto ya hemos mencionado una propuesta anteriormente.
En nuestro caso tuvimos que aportar experiencia en el área de desarrollo para poder establecer
límites como requerimiento, esto solamente con la intención de aclarar el camino que hemos
seguido para llevar a cabo el modelado requerido para nuestro proyecto, y partiendo de las ideas
iniciales planteadas.
Modelo UML
A continuación llevaremos el planteamiento anterior a una definición formal, para ello nos
apoyaremos de UML, definiremos los distintos diagramas UML del modelo propuesto para que
podamos partir de esto hacia el desarrollo como un proyecto de software.
En este punto no hablaremos de los detalles de UML o bien su uso, nos limitaremos a definir el
modelo que hemos propuesto mediante los diagramas de UML más comunes en el desarrollo de
un proyecto informático.
Cuando hablamos de un proyecto de software, resulta difícil hacer la definición del modelo que se
requiere para satisfacer cierta necesidad mediante la creación de un programa informático, en
nuestro caso concentraremos el modelaje, en los componentes requeridos para un escenario
decisorio experimental, pero en cuanto funcionalidad no podemos limitar nuestro modelo para el
escenario decisorio experimental, modelaremos también los componentes del sistema que serán
requeridos para su operación, tales son los módulos que compondrán el software y mediante los
cuales se podrá tener acceso a los escenarios decisorios experimentales.
Por otro lado queremos también aclarar que estos diagramas que definiremos a continuación los
definimos pensando no solamente en un escenario decisorio experimental, como ya hemos
28
mencionado, trataremos que el modelo de implementación en UML sea lo suficientemente
flexible para adaptarse a los diferentes escenarios decisorios experimentales que requieran ser
modelados.
Para poder generar el modelo de nuestro proyecto como un programa informático, nos basaremos
en la definición de los requerimientos funcionales que hemos propuesto en la Propuesta del
proyecto y también en los módulos que hemos definido necesarios para nuestro sistema.
Diagrama general
Iniciamos con el diagrama general del modelo de nuestra propuesta.
Figura 7 - Diagrama general del sistema
Fuente: diseño propio
En la Figura 7, podemos observar el modelado del sistema mostrando los componentes que
proponemos y la relación que tendrán con los usuarios. Aquí podemos ver que existirán dos tipos
de usuarios, el Experimentador, quien es el interesado en obtener resultados de los experimentos
realizados, y los usuarios quienes participaran en los eventos de los escenarios decisorios
experimentales. Aquí observamos claramente que el experimentador es quien definirá los
experimentos, creará los eventos de participación y llevara a cabo el análisis de los resultados
obtenidos.
29
Casos de uso
A continuación presentamos los casos de uso para los módulos propuestos que compondrán
nuestro sistema.
Experimentos
Como ya se ha mencionado, el módulo de Experimentos es donde el usuario experimentador,
definirá los experimentos, que podrán realizarse haciendo uso del sistema propuesto, el
experimentador definirá el nombre, una descripción, los parámetros y la definición lógica del
escenario, esto es el experimentador, definirá el escenario decisorio experimental, incluyendo sus
elementos, propiedades y reglas de interacción, aquí solo nos hace falta los agentes racionales, se
definirán también, pero solamente como una cantidad, ya que en este momento solamente se
hará la definición de los escenarios decisorios.
Figura 8 - Casos de uso Módulo Experimentos
Fuente: diseño propio
Definir experimentos
Este caso de uso permitirá al usuario experimentador, definir los experimentos que existen en el
sistema, esto es, su nombre, descripción, y características que ya hemos mencionado.
30
Figura 9 - Caso de uso Definir experimentos
Fuente: diseño propio
Consultar experimentos
Este caso de uso permitirá al usuario experimentador, consultar los experimentos existentes en el
sistema, solamente podrá verificar la información existente con respecto a los experimentos, no a
los eventos y no podrá realizar ningún cambio.
Figura 10 - Caso de uso Consultar experimentos
Fuente: diseño propio
Ajustar parámetros experimentos
Este caso de uso permitirá al usuario experimentador, realizar cambios en los experimentos que
existen en el sistema.
31
Figura 11 - Caso de uso Ajustar parámetros experimentos
Fuente: diseño propio
Eventos
En el módulo de eventos, el experimentador tendrá la capacidad de crear eventos o instancias de
los escenarios decisorios experimentales, al momento de crear estos eventos, el experimentador
podrá ajustar los parámetros de cada uno de los eventos por separado. Al crear el evento, el
experimentador, prepara un escenario decisorio experimental, para que un usuario o varios
usuarios participantes puedan ingresar a él y participar, esto será en el módulo de participación
que definiremos más adelante.
Figura 12 - Casos de uso Módulo Eventos
Fuente: diseño propio
Crear evento
Este caso de uso tiene como fin que el experimentador pueda crear eventos de los escenarios
decisorios experimentales, podrá crearlos de acuerdo a la definición predeterminada para ellos o
bien podrá modificar sus parámetros de inicio.
32
Figura 13 - Caso de uso Crear evento
Fuente: diseño propio
Análisis
Este módulo, permitirá al experimentador observar los resultados de los eventos que ya han sido
finalizados, aquí el experimentador podrá observar el comportamiento que tuvieron las
propiedades de los escenarios, bien de manera aislada o en conjunto por un grupo de
experimentos que hayan sido llevados a cabo.
Figura 14 - Casos de uso Módulo Análisis
Fuente: diseño propio
33
Obtener resultados
Este caso de uso permitirá al usuario experimentador, recabar la información de los resultados de
los eventos que hayan sido generados en el sistema.
Figura 15 - Caso de uso Obtener resultados
Fuente: diseño propio
Participar
Este módulo está pensado para que los participantes tengan la interacción con los eventos creados
por el experimentador. De tal forma que el módulo presenta el escenario decisorio experimental y
facilita a los participantes los elementos para interactuar con el escenario decisorio experimental.
34
Figura 16 - Casos de uso Módulo Participar
Fuente: diseño propio
Participar en evento
Este caso de uso permitirá a los participantes interactuar con los eventos creados por el usuario
experimentador. Específicamente en este caso de uso pondremos mucha atención, forma parte
importante de la aplicación ya que permite la obtención de los resultados de la experimentación y
además es aquí donde el sistema deberá tener la capacidad de presentar a los participantes
diversos tipos de escenarios y permitir la interacción entre los participantes en un escenario
decisorio experimental.
Figura 17 - Caso de uso Participar en evento
Fuente: diseño propio
35
Diagrama de clases
Continuaremos con el modelo de los diagramas de clases que requeriremos para satisfacer la
necesidad que surge de la propuesta realizada.
Figura 18 - Diagrama de clases UML
Fuente: diseño propio
Hasta ahora los diagramas presentados no describen de forma completa la interacción que será
llevada a cabo por los participantes en los escenarios decisorios, a continuación presentaremos los
diagramas donde podremos observar el comportamiento del sistema completo, y el detalle del
comportamiento de un evento de un escenario decisorio experimental.
Diagrama de secuencia
Primero presentaremos el diagrama de secuencia del sistema en general, para plasmar el
comportamiento que tendrá el sistema completo, esto es, desde el momento en que se capturan
los escenarios decisorios experimentales, la creación de los eventos, la participación de los
agentes racionales y por último la obtención de los resultados.
Sistema
El siguiente diagrama contempla la secuencia que siguen los datos a través del sistema en
conjunto
36
Figura 19 - Diagrama de secuencia del sistema
Fuente: diseño propio
En el diagrama anterior observamos la secuencia de datos del sistema completo, pero es muy
importante hacer notar, el flujo que se llevará a cabo para cada uno de los escenarios decisorios
experimentales.
Escenario decisorio experimental
Ahora que hemos definido la secuencia del sistema completo definiremos la secuencia para los
escenarios decisorios experimentales.
37
Figura 20 - Secuencia de Evento Escenario decisorio experimental
Fuente: diseño propio
En la figura anterior, simplemente separamos el ciclo de vida del evento, para mostrar como el
comportamiento es en un ciclo, que comprende varias participaciones, estas participaciones son
llamadas por el evento de escenario decisorio experimentación y envían un mensaje de respuesta
al evento de escenario decisorio experimental, el evento, evalúa la respuesta registra el
acontecimiento y continua con el ciclo o bien verifica si se ha cumplido alguna condición que
indique el final del escenario decisorio experimental y en tal caso da por terminado el evento.
Con los diagramas anteriores hemos plasmado una definición de nuestro proyecto con la cual
podemos comenzar a desarrollar un proyecto de software, lo cual veremos en el capítulo siguiente.
38
CAPÍTULO III DESARROLLO
En el presente capítulo describiremos el proceso de desarrollo que fue llevado a cabo durante
nuestro trabajo, los problemas que se presentaron y las soluciones que se dieron, se explicará el
detalle de los ajustes necesarios llevados a cabo para la obtener los resultados esperados.
Es probable que se encuentre una discrepancia al inicio del presente capítulo, con lo que
mencionamos en el capítulo anterior, cabe aclarar que el desarrollo del presente trabajo implicó
un enfoque diferente al que normalmente hemos manejado tanto el nuestra experiencia
académica como en la laboral, por lo cual fue necesario realizar investigación técnica e infinidad
de pruebas, hasta obtener el resultado deseado.
Preparación de ambiente
Debido a que nuestro objetivo es crear una aplicación web, se utilizará la tecnología Java debido a
los beneficios y facilidades que nos puede proporcionar para los objetivos requeridos por el
presente trabajo.
Como ya lo hemos mencionado y para satisfacer la propuesta realizada en el capítulo anterior
tenemos que: el sistema se dividirá en dos partes principales, una es el servidor que se encargará
de almacenar el detalle de la aplicación, almacenar la información obtenida, programar y
coordinar las interacciones entre los participantes y almacenar los resultados para su posterior
análisis.
En contraparte, en el lado del cliente, se encargará de poder presentar los escenarios a los
participantes y permitir la interacción requerida entre ellos y los escenarios definidos.
Tomando en cuenta que se usará Java como marco de trabajo para el servidor y que el cliente será
por medio de una aplicación web proponemos como tecnologías a usar las siguientes:
Cliente:
• HTML 5
• CSS
• JavaScript
39
Servidor:
• Apache Tomcat Server
• Java
El software con el cual iniciamos fue el siguiente:
• Eclipse Kepler
• Java JDK 7
• MySQL Server
Debido al análisis realizado previamente al inicio del desarrollo se planeó hacer uso del framework
“Spring” para poder desarrollar rápidamente la aplicación usando el modelo MVC y programación
orientada a Aspectos, pensando en los beneficios que podemos obtener de él en cuanto al
modelaje e implementación a la que queremos llegar. Hace falta mencionar que no somos
expertos en el uso de estas tecnologías así que el presente trabajo también requirió de un gran
esfuerzo de investigación y pruebas para obtener los resultados deseados, describiremos el detalle
a lo largo del presente capítulo, así como también explicaremos los cambios que fueron realizados.
Instalación de ambiente
Se procedió a realizar la instalación del ambiente para el desarrollo el cual consistió en los
siguientes pasos:
• Instalación de MySQL
• Instalación de Java JDK
• Instalación de Eclipse
No haremos mención de los detalles de instalación ya que no se consideran relevantes para el
desarrollo, este detalle puede ser consultado en el ¡Error! No se encuentra el origen de la
referencia..
Primer acercamiento
Para alcanzar el resultado deseado del presente trabajo, se determinó que el punto de partida
óptimo sería comenzar con un escenario decisorio experimental, posteriormente generalizar la
40
solución y poder aplicarla a diferentes escenarios, teniendo como base la solución que se le dio al
primer problema resuelto y sobre la cual sea posible mediante un esfuerzo realizar la
implementación para diferentes escenarios, lo anterior se debe a las siguientes razones:
• La necesidad que plantea nuestro trabajo sale un poco del uso común que le damos a las
TI, específicamente en el desarrollo de aplicaciones web, nos referimos a que es una
necesidad cuya naturaleza es diferente de las que hasta el día de hoy hemos trabajado.
• En nuestro caso el uso de tecnología Java hasta la fecha ha sido limitado, motivo por el
cual no podemos considerarnos expertos en esta tecnología, se hace un esfuerzo de
investigación y uso adicional para los fines requeridos de nuestro trabajo.
Por los motivos expuestos anteriormente se decidió comenzar haciendo la implementación del
experimento “Ultimátum o el dictador”, el objetivo de esto es iniciar con la solución de un
escenario decisorio experimental para después poder generalizarlo, de manera que sea fácil la
implementación de otro escenario decisorio experimental.
Ultimátum o el dictador
De forma breve el experimento de “Ultimátum o el dictador” consiste en:
Se requiere que una cantidad de dinero sea dividida entre dos personas, una persona decidirá el
monto de la división (moderador) mientras la otra persona (participante) podrá aceptar o rechazar
la oferta propuesta por su contraparte.
De acuerdo al modelo conceptual establecido en el capítulo anterior podemos descomponer el
experimento de la siguiente manera:
Ultimátum o el dictador
Elementos Descripción Propiedades Interacción Objetivos
Escenario Define el marco
de interacción
Cantidad de dinero a
dividir
- -
Moderador Participante Cantidad de dinero a
recibir
Puede definir el
monto de la división
Obtener la mayor
ganancia posible
41
del dinero
Participante Participante Cantidad de dinero a
recibir
Puede aceptar o
rechazar la propuesta
realizada por el
moderado
Obtener la mayor
ganancia posible
Tabla 1 - Ultimatum o el dictador Fuente: diseño propio
En términos prácticos, el objetivo de ambos participantes es obtener el mayor beneficio posible
del acuerdo al que se pueda llegar con su contraparte (moderador – participante).
Requerimientos funcionales
• Los participantes se conectarán desde terminales distintas (clientes)
• Cada participante tiene un turno de participación por un turno de espera
• Cada participante puede dar seguimiento al estado del juego de acuerdo al turno que le
corresponda
• El moderador podrá realizar la división de la cantidad en juego
• El participante solamente podrá aceptar o rechazar la oferta del moderador una vez que
esta oferta se haya realizado
• El juego termina una vez que el participante decide aceptar la cantidad ofrecida por el
moderador
• Los clientes recibirán las actualizaciones de estado por el sistema, nos referimos a que no
será necesario que el cliente solicite una actualización del estado desde el servidor, esto se
explica a detalle en las limitaciones tecnológicas.
La descripción de requerimientos anterior puede resultar sencilla, pero si observamos
detenidamente podemos percatarnos que resulta hasta cierto punto complejo crear una
aplicación web que nos permita realizar esta interacción entre los clientes de manera inmediata.
Limitaciones tecnológicas
Hacemos una breve pausa en la implementación del escenario experimental “Ultimátum o el
dictador” para mencionar algunas limitantes tecnológicas que se tienen para la implementación de
los puntos mencionados anteriormente, esto tiene el fin de que se tenga una idea de la
complejidad de parte de los desafíos encontrados a lo largo del desarrollo del presente trabajo.
42
Notificaciones de estado e intercambio de contenido sobre internet
Actualmente existen diversas aplicaciones de comunicación que son utilizadas sobre una
infraestructura de red llámese una LAN o Internet, estas aplicaciones permiten el intercambio de
diferentes tipos de contenido como imágenes, audio, video, etc. Lo anterior con el fin de poner en
contexto las capacidades que es posible implementar en aplicaciones web, recordemos que parte
del objetivo de nuestro trabajo es que un cliente, pueda ingresar haciendo uso de un navegador
web, nos referimos a que la funcionalidad se ve reducida a aquella que un navegador web nos
permite realizar, esto es además sin hacer uso de componentes adicionales como plugins.
Un requisito para la aplicación es que los clientes sean notificados de los cambios que se lleven a
cabo en el escenario en cuestión, para lo cual observamos una limitante que viene de la naturaleza
del protocolo HTTP esto es debido a que la comunicación la inicia el cliente y no se mantiene una
conexión activa entre cliente – servidor -cliente para el intercambio de actualizaciones de estado y
mucho menos notificaciones del escenario en cuestión.
Este problema se podría solucionar de forma relativamente rápida haciendo uso de algún
componente externo al navegador web que nos permitiera, realizar una comunicación continúa
entre cliente y servidor, pero evitaremos esto y trataremos de utilizar simplemente las
capacidades propias del navegador web.
Mencionaremos de forma breve las características del protocolo HTTP, posteriormente y para
llevar a cabo la implementación de esta tarea validamos diferentes opciones tecnológicas que
mencionaremos brevemente.
Protocolo HTTP
A continuación daremos una breve descripción del protocolo HTTP, que es con el que estaremos
trabajando para llevar a cabo la comunicación entre nuestro sistema y los clientes que se conecten
a él.
Actualmente el protocolo HTTP, es el más ampliamente utilizado para la creación de aplicaciones
web, la revisión mayormente utilizada es la HTTP 1.1 (RFC 2616) publicada en 1999.
HTTP es un protocolo que está orientado a transacciones y sigue un esquema de petición –
respuesta, la petición es realizada por un agente al que se le llama “cliente” y por otro lado quien
43
atiende la petición es un agente llamado “servidor”. La petición está definida por un identificador
llamado URL, que identifica el recurso solicitado por el “cliente”. En este esquema de petición
respuesta la comunicación siempre es iniciada por el “cliente”, y una vez que la respuesta del
servidor ha sido enviada al cliente, la conexión entre ambos es cerrada.
HTTP es un protocolo “sin estado” esto quiere decir que no tiene manera de guardar información
sobre peticiones anteriores, por lo cual se echa en mano de otros recursos para poder dar
seguimiento a los “clientes”.
Web sockets
Es una tecnología relativamente nueva, la cual permite crear un canal de comunicación
bidireccional y full duplex, entre cliente y servidor, está diseñada para ser implementada en
navegadores y servidores web, al ser relativamente nueva, aún se encuentra en proceso de
normalización por el W3C.
La implementación en el cliente y es por medio de una API de JavaScript, la cual resulta sencilla de
implementar para una aplicación web, por otra parte en el servidor también se requiere la
implementación de un servidor o componente que soporte esta tecnología, en nuestro caso
recordemos que estamos trabajando como un servidor Apache de tecnología Java. Haciendo un
poco de investigación encontramos un Framework llamado Thymeleaf, que de acuerdo a la
documentación soporta el protocolo Web Sockets del lado del servidor, y promete también una
implementación sencilla.
El uso de Web sockets, parecía al principio la opción adecuada para la implementación requerida,
realizamos bastantes pruebas con el uso de los componentes mencionados en el párrafo anterior,
y nos encontramos con muchos problemas en la implementación los cuales no pudieron ser
mitigados. En primer lugar nos encontramos que existan diferencias en la implementación de la
API para los distintos navegadores web que existen actualmente, en principio esto provoca
conflicto para la implementación en el lado del cliente, lo cual se puede solventar adaptando el
código para que sea compatible con los diferentes navegadores, ésta no es la parte complicada, ya
que posteriormente nos encontramos con problemas de compatibilidad en las librerías de
Thymeleaf con las de Spring, no mencionaremos el detalle ya que nos saldríamos del tema
principal que en este breve apartado trata de mencionar someramente estos problemas,
44
solamente diremos que debido a los beneficios que nos podría traer y lo atractivo de su
implementación y características invertimos mucho tiempo en tratar de obtener una solución
utilizando esta tecnología. Al final decidimos optar por buscar más opciones ya que después de
algún tiempo no tuvimos resultados satisfactorios.
Http server push
Aquí se consideran diferentes mecanismos, los cuales tienen como objetivo el envío de datos
desde el servidor hacia el cliente, es sin que exista de por medio una petición explícita. Existen dos
mecanismos de este tipo que analizamos y llegamos a considerar como una posible alternativa de
solución los cuales describiremos a continuación.
El primero consiste en que el servidor deja abierto el canal de respuesta una vez que ha enviado
todos los datos al cliente, esto en caso de que exista alguna notificación que desee ser enviada al
cliente para que así pueda ser enviada de forma inmediata, un problema importante con esta
solución consiste en que el canal sea interrumpido, los datos no pueden ser entregados al cliente
hasta que el cliente realice una petición explícita nuevamente al servidor.
El segundo mecanismo consiste en el uso de un tipo MIME especial llamado multipart/x-mixed-
replace, este tipo debe ser interpretado como un cambio en el documento en el momento en que
el servidor envía una notificación de cambio de estado al cliente, puede ser aplicado a documentos
de tipo HTML o bien aplicaciones de difusión de imágenes, el problema con este mecanismo es
que no tiene una amplia implementación en los navegadores.
En ambos casos antes mencionados se abre una importante brecha de seguridad y rendimiento en
el servidor, al tener abierta una conexión de respuesta hacia el cliente y más aún no es posible
garantizar la estabilidad de la conexión.
Por los motivos antes expuestos y después de realizar algunos experimentos decidimos buscar una
alternativa para cumplir el fin que buscamos lo cual conseguimos de la siguiente forma.
Http pull
Después de haber realizado una serie de experimentos con los métodos antes descritos, llegamos
a la conclusión que resultaría más sencillo en términos de tiempo y esfuerzo realizar la
implementación tradicional usando el método HTTP pull. Este método consiste en enviar desde el
45
cliente solicitudes de actualización de estado hacia el servidor usando peticiones HTTP GET/POST
sobre AJAX, usando un script que solicite actualizaciones de estado cada determinado tiempo, esta
implementación es relativamente sencilla sólo que implica una carga adicional a la conexión, esto
lo tenemos en cuenta para el diseño de las peticiones y respuestas que serán enviadas en la
comunicación establecida entre cliente y servidor tratando de minimizar el impacto que pueda
llegar a afectar la operación del sistema.
Después de realizar una serie de pruebas utilizando este método, decidimos utilizarlo para la
implementación de notificaciones de cambios de estado en el sistema, observamos además que
un tiempo óptimo puede variar pero para que resulte de forma casi imperceptible el retardo que
existe entre petición y petición decidimos establecer este período en un tiempo de 500 ms, esto es
dos peticiones por segundo, consideramos que para los escenarios que tendremos en cuestión ha
hasta el momento este es un tiempo aceptable de respuesta por lo cual llevamos a cabo la
implementación sobre este mecanismo.
Para llevar a cabo la implementación con http pull, se tuvieron que hacer ajustes a la
implementación inicial que describiremos adelante, por el momento adelantaremos que la
implementación que se realizó o de lado del servidor fue con ayuda de un servlet de Java,
especializado en la atención de estas peticiones.
Almacenamiento de información
Otra meta importante a cumplir en el cual radica mucha de la complejidad de la implementación
del sistema es el almacenamiento de la información requerida ya que el sistema deberá ser capaz
de manejar diferente tipo de información como lo enlistaremos a continuación. La lista siguiente
solamente contempla aquella información que consideramos relevante y diferente a los tipos de
dato que normalmente son almacenados en una base de datos.
Componente del
sistema
Información requerida Estrategia Inicial Propuesta
Escenarios decisorios
experimentales
• Características
o Nombre
o Descripción
La propuesta inicial consiste en que los
escenarios decisorios experimentales sea
generados en sistema como una librería Java en
46
o Participantes
• Elementos
• Propiedades
• Reglas de interacción
• Interfaces
• Recursos
un archivo jar, el cual pueda ser invocado
haciendo uso de las bondades que nos ofrece la
AOP, de forma tal que este archivo jar pueda
serializarse de formar binaria, para invocarlo de
forma dinámica durante la ejecución
Instancias de los
escenarios decisorios
experimentales
• Eventos
o Parámetros
La propuesta inicial consiste en que se genere la
instancia del objeto que representa el escenario
decisorio experimental una vez que ha sido
inicializado con los parámetros requeridos, que
sea serializado posteriormente en binario, para
almacenarlo en la base de datos, recuperarlo
posteriormente cuando sea requerido para la
experimentación y restaurarlo como un objeto
a partir de la información binaria serializada.
Resultados obtenidos
de los experimentos
realizados
• Resultados
La propuesta inicial consiste en tener campo de
texto en la base de datos donde se almacene un
archivo de resultados en formato XML, de
forma que sin importar el tipo de dato que se
espere desde el escenario decisorio
experimental la información se almacene
indistintamente en la base de datos
Tabla 2 - Propuesta inicial de almacenamiento de la información Fuente: diseño propio
En la Tabla 2, observamos que el almacenamiento la información consiste en todo un reto para un
modelo estándar de base de datos, ya que no es posible definir un modelo de datos en el que sea
posible almacenar la información de diferentes escenarios decisorios experimentales, y por otro
lado hay que resolver el problema que implica la construcción de los escenarios decisores
experimentales, esto es común se almacenarán y como serán generadas sus instancias tanto en el
sistema como en la base de datos, estas son las razones que nos llevan a la propuesta realizada
47
anteriormente, más adelante veremos el resultado que dio la propuesta realizada y los ajustes que
debieron ser realizados.
Implementación de lógica adaptable
Proponemos el término lógica adaptable, para referirnos a la implementación de la lógica de los
escenarios decisorios experimentales que serán implementados con ayuda de nuestro sistema. A
qué nos referimos con esto, nos referimos a que cada uno de los escenarios decisorios
experimentales tendrá reglas lógicas diferentes y estarán compuestos por diferentes estados
lógicos como lo hemos propuesto en el capítulo II. Pero aquí es donde viene el verdadero reto
informático que implica una implementación donde se puedan soportar diferentes escenarios
decisorios experimentales de forma tal que no se requiera de un esfuerzo mayor para poder
realizar la implementación de diferentes escenarios decisorios experimentales, para ello
inicialmente se propone echar mano de las bondades que ofrece la AOP, que nos proporciona el
Framework Spring, aprovechando el modelo de programación MVC.
Como veremos más adelante y después del primer acercamiento fue necesario realizar algunos
ajustes en cuanto a la propuesta inicial que presentamos debido a las dificultades que se
presentaron y las ventajas que representaban otros modelos que explicaremos más adelante.
Implementación del modelo lógico Ultimátum o el dictador
Retomando el experimento de “Ultimátum o el dictador” como punto de partida en el desarrollo
de nuestro trabajo, comenzaremos con la implementación del modelo lógico de este escenario. En
esta implementación comenzaremos por aplicar la propuesta realizada en el capítulo dos como
una solución ad hoc para éste el escenario decisorio experimental.
Modelo lógico del escenario decisorio experimental “Ultimátum o el dictador”
De acuerdo a la propuesta realizada en el capítulo II, presentamos el desarrollo de este modelo
para el escenario decisorio experimental “Ultimátum o el dictador” y retomando la Tabla 1.
48
Figura 21 - Flujo de Ultimatum o el dictador
Fuente: diseño propio
En la Figura 21, observamos cómo se aplica nuestra propuesta del escenario decisorio
experimental “Ultimátum o el dictador”, solo hemos presentado el diagrama de flujo del escenario
mencionado, no entraremos en detalle de la implementación UML, ya que el modelo UML
propuesto para la implementación es un modelo generalizado el cual se adaptará a cada uno de
los diferentes escenarios decisorios experimentales, la Figura 21, tiene como objetivo ilustrar el
flujo que sigue el escenario decisorio experimental en cuestión, para que tengamos presente el
flujos del implementación que realizaremos a continuación.
49
Ahora procedemos a la implementación de nuestro modelo propuesto en el escenario decisorio
experimental que estamos tratando en este apartado, comenzaremos con el desarrollo de la
solución ad hoc que nos ha dado una orientación para el desarrollo general de la solución.
Desarrollo
Comenzamos trabajando en el desarrollo de esta solución, como una aplicación web en nuestro
ambiente de Eclipse, recordemos que el objetivo a alcanzar en este momento nos servirá como
base para reutilizar los componentes de almacenamiento, lógica, presentación y comunicación.
Aunque el hogar en el cual haremos el desarrollo técnico no será el mencionado en el párrafo
anterior. Tampoco entraremos mucho en el detalle de la implementación técnica nos limitaremos
a decir cuáles fueron los puntos esenciales, los problemas encontrados, las soluciones, los cambios
y ajustes que tuvieron ser realizados para llegar al implementación deseada.
Decidimos plantear como contexto de ejecución de Spring el escenario decisorio a modelar
teniendo así que los elementos que compondrían a este contexto serían creados por Beans
haciendo uso de las facilidades que nos brinda el modelo de AOP con Spring y MVC, a continuación
se presenta un diagrama donde explicamos cómo se pretendía realizar esta implementación.
50
Figura 22 - implementacion MVC Ultimatum Fuente: diseño propio
Almacenamiento
Iniciamos con una base de datos que consta de una tabla que almacena solamente la siguiente
información:
• Fecha y hora de evento
• Tipo de evento
• Cantidad de dinero inicial
• Porcentaje persona A
• Porcentaje persona B
La base de datos anteriormente mencionada no tiene mayor complicación debido a que esta
información bien se puede almacenar dentro de una sola tabla que fue generada como tal.
51
Posteriormente generamos una capa de acceso a datos desde nuestro proyecto o de aplicación
web en eclipse.
No generamos un modelo de datos específico para esta aplicación, ya que no agrega un valor a lo
que queremos tener en este punto, recordemos que el resultado deseado en este momento es
una base técnica sobre la cual podamos generalizar la solución.
Lógica
En cuanto a la parte de la implementación de la lógica para este escenario decisorio experimental,
no existió mayor problema en cuanto al modelo propuesto con MVC para realizar la
implementación, las reglas lógicas a seguir son sencillas y se pueden plasmar fácilmente en una
clase Java la cual tenga el control sobre la negociación teniendo en ella tres propiedades
principales las cuales son:
• Cantidad de dinero total
• Cantidad moderador
• Cantidad participante
Por otro lado los métodos que componen esta clase se propone que queden de la siguiente forma:
• Ofertar: Es ejecutada por el moderador y se encarga de realizar la división de la cantidad
en de lo total entre moderador y participante.
• Rechazar: Es ejecutada por el participante en caso que decida no aceptar la oferta
realizada por el moderador.
• Aceptar: Es ejecutada por el participante en caso o que decida aceptar la oferta realizada
por el moderador, también finaliza el escenario.
Estas funciones son implementadas como parte del contexto o bien del escenario decisorio
experimental y como hemos visto se encargan de llevar el control lógico requerido para la
interacción con los usuarios. Hasta este momento no hay mayor complicación en cuanto a la
implementación del escenario pero aún nos hace falta llevar esta interacción hasta los clientes de
esto se encargará el controlador y lo veremos a detalle en el desarrollo del mecanismo de
comunicación.
52
Por el momento basta decir que con el desarrollo expuesto hasta el momento se satisface la parte
de la implementación de la lógica de nuestro escenario decisorio experimental, el servidor tiene el
contexto del escenario como un objeto al cual le puede dar seguimiento y satisface nuestra
necesidad actual.
Presentación
Ahora bien en la parte de implementación de la presentación que se encargará de presentar la
información recibida desde el servidor que es el escenario decisorio experimental, hacia los
participantes en sus respectivas terminales web, se requiere que ambos clientes implicados en una
instancia del escenario decisorio experimental tengan diferentes vistas de la misma instancia en el
mismo momento y además puedan recibir las actualizaciones del status del escenario en el
momento en que su contraparte realizada una operación un cambio en el escenario decisorio
experimental de esta forma tenemos que las vistas requieren los siguientes componentes:
Moderador
Control Acción
Texto Presentar la cantidad de dinero a dividir
Slider Dividir la cantidad de dinero
Botón Realizar la oferta al participante
Texto Presentará el estatus cuando el participante toma una decisión
Tabla 3 - Controles Vista Moderador Fuente: diseño propio
Participante
Control Acción
Texto Presentar la división del dinero propuesta por el moderador
Botón Aceptar la oferta
Botón Rechazar la oferta
53
Texto Presentar el estatus cuando el moderador hace una oferta
Tabla 4 - Controles Vista Participante Fuente: diseño propio
En este punto la única complicación que se puede presentar pero que no representa un gran reto
consiste en presentar la vista correspondiente para cada uno de los clientes conectados al
escenario decisorio experimental, pero esto se consiguió solventar de una forma relativamente
sencilla.
Ahora bien una vez que hemos realizado esta implementación nos encontramos que
prácticamente cada uno de los clientes debe tener una copia del escenario decisorio experimental
de manera local y prácticamente se debe realizar la implementación de la lógica en la capa de
presentación (vista) en los clientes para de esta forma permitir que el controlador comunique de
manera bidireccional los cambios de estado desde y hacia el servidor.
Llegados a este punto, comenzamos a observar que no solamente el servidor debe conocer el
estado del escenario en todo momento, sino que también los clientes deben conocer el estado del
escenario en todo momento, como ya lo hemos mencionado esto implica que una buen parte de
la lógica que es implementada en el servidor como parte del escenario decisorio experimental, es
reconstruida en el cliente usando una tecnología diferente a la usada en el servidor, por lo cual
debemos “duplicar” en cierto sentido el trabajo realizado para la implementación del escenario.
Comunicación
El aspecto de comunicación es muy importante el desarrollo de nuestro trabajo, los clientes
debían estar enterados en el menor tiempo posible de los cambios de existentes en el escenario
decisorio experimental para poder solicitar adecuadamente la interacción de los usuarios en el
momento que fuera requerido. Por otro lado el servidor debía tener en todo momento el estado
del escenario decisorio experimental actualizado de acuerdo a las entradas producidas por los
clientes, de esta forma el servidor y cada uno de los clientes tenían en el menor tiempo posible el
escenario decisorio experimental replicado, el servidor para realizar las mediciones
correspondientes, mientras que los clientes podrían interactuar con el escenario de la manera más
inmediata posible.
54
Como ya lo mencionamos, se hizo uso de http pull para realizar la actualización de estado de los
clientes, para esto ya hemos realizado algunas pruebas previas y fue así que decidimos usar este
método.
Aquí el problema radica en que el flujo de información va desde el cliente hacia el servidor, hay
que resolver el problema que consiste en que la instancia del escenario decisorio experimental
pueda sincronizar la interacción que existe entre sus participantes, o dicho de otra forma que los
escenarios locales de cada cliente se encuentren actualizados en todo momento, el problema de
que esto implica se explica a continuación.
Figura 23 - Implementación de comunicación Ultimatum Fuente: diseño propio
En la Figura 23 observamos un modelo muy similar a una aplicación web el cliente servidor, aquí
hacemos la aclaración la figura nos muestra un escenario decisorio experimental de ultimátum
donde tenemos un moderador y un participante, la líneas continuas representan las solicitudes de
los clientes por cambios en el estatus del escenario decisorio, y las líneas punteadas representan la
respuesta del servidor para estas peticiones estas respuestas se presentan a continuación.
55
Respuesta Destinatario Acción en el cliente
En espera de inicio Moderador, Participante Mostrar mensaje de espera a
clientes
Solicitar oferta Moderador Mostrar interface para realizar
oferta
En espera de oferta
moderador Participante
Mostrar mensaje de espera de
oferta moderador
El moderador ha realizado
una oferta Participante
Mostrar oferta realizada e
interface para aceptar o
rechazar la oferta
En espera de respuesta
participante Moderador
Mostrar mensaje de espera de
acción participante
El participante ha rechazado
la oferta Moderador
Mostrar interface para realizar
oferta
El participante ha aceptado la
oferta Moderador -
Fin del juego Moderador, Participante Finalizar escenario decisorio
Tabla 5 - Respuestas actualizacion de estado Ultimatum Fuente: diseño propio
Para llevar a cabo la comunicación anterior y evitar saturar el canal de comunicación por las
continuas peticiones de actualización de estado, se hace uso de comunicación mediante AJAX, a
pesar de esto el modelo que estamos utilizando MVC, requiere que se transmita demasiada
información en las peticiones realizadas por los clientes al servidor ya que se requiere conocer el
estado de la página completa y por otro lado en el momento de obtener la respuesta del servidor
esta es prácticamente la página completa con sus respectivas modificaciones que reflejan el
cambio de estado en el escenario decisorio experimental.
56
Por lo tanto nos topamos con que esta implementación implica una demanda alta de datos que
había podido parecer insignificante, pero recordemos que las peticiones se realizarán con
intervalos de 500 ms, se tomamos en cuenta el tamaño promedio de una página de este tipo que
oscila alrededor de los 500Kb, requeriríamos que nuestros clientes tuviesen al menos una
conexión con un ancho de banda mínimo de 1Mb por segundo, esto es un requisito técnico que
puede impactar de manera significativa al rendimiento del aplicación en el lado del cliente.
Hallazgos
Hasta el momento de la implementación realizada ha sido laboriosa, y cuando decimos laboriosa,
nos referimos a que fue un esfuerzo muy grande en términos de tiempo, investigación y pruebas
experimentales que tuvieron que ser realizadas. Queremos decir con estuvo que aunque el
planteamiento expuesto parezca sencillo y el resultado también lo parezca, la implementación no
fue nada sencilla.
La parte más complicada de la implementación fue realizar el trabajo doble de la implementación
del escenario, tanto en el servidor como en los clientes, además de ello, la sincronización del
estado del escenario en el servidor con el estado en los clientes resulta laboriosa en términos de
programación aunque lo que hemos presentado aquí resulta hasta cierto punto sencillo la verdad
es que nos damos cuenta que replantear un modelo general utilizando esta solución con este
modelo resultaría complicado.
Ahora que hemos visto las complicaciones que se han presentado y hemos desarrollado soluciones
específicas para ellas, nos damos cuenta que esta opción que hemos tomado no es la óptima para
realizar una implementación general, por otro lado encontramos lo que se requiere para satisfacer
las necesidades de nuestro requerimiento, es necesario eliminar la doble implementación que se
tiene un lado en el servidor y por el otro en el cliente, ya nos hemos percatado que el servidor no
necesita tener conocimiento en todo momento del estado del escenario decisorio experimental,
quienes en verdad lo requieren son los clientes conectados al escenario decisorio experimental.
Pero en verdad es esto posible como pretendemos hacer que los clientes tengan una versión
actualizada del escenario decisorio experimental en todo momento, sin necesidad que el servidor
tenga esta información.
57
Un punto importante y que consideramos de alta prioridad, es el tema de los peticiones que los
clientes realizan al servidor las respuestas que el servidor regresa para que los clientes puedan
tener conocimiento del estado actual del escenario. Como ya lo mencionamos nuestra
implementación actual tiene un consumo alto en términos de datos transmitidos, lo cual
requerimos disminuir tanto como sea posible.
Ajustes
En primer lugar hacemos un cambio en cuanto al modelo que fue propuesto inicialmente para
satisfacer las necesidades de nuestro sistema, recordemos que estamos utilizando el patrón de
desarrollo MVC, el cual sustituiremos por MVVM, este último es derivado de MVC pero tiene
algunas mejoras bastante significativas, implica que el controlador ya no será necesario para la
implementación de nuestros escenarios decisorios experimentales, dejando solamente el modelo
y la vista, la comunicación entre estos dos es directa.
El cambio anterior puede parecer insignificante, pero en realidad nos trae muchas ventajas las
cuales son:
• Se elimina el controlador como implementación lógica en servidor, esto implica que no
tendremos un trabajo doble de implementación del escenario decisorio experimental.
• Al eliminar la implementación lógica en el lado del servidor, nos quitamos un problema
importante el cual es la creación y almacenamiento de la parte lógica en el lado del
servidor, ya veremos la solución que se le dio posteriormente a este problema.
• Los clientes se encargarán de generar su propia instancia del escenario decisorio
experimental y llevar el control de ella simplemente realizando notificaciones de los
cambios al servidor, quien se encargará de comunicar estos cambios a los demás clientes
implicados en el escenario decisorio experimental.
• La implementación del modelo y la vista será totalmente pensada para el cliente, de esta
forma minimizamos el impacto en el procesamiento del servidor así como en la
transmisión de información entre peticiones.
• El servidor no requerirá conocer el estado del escenario decisorio experimental en todo
momento, simplemente se encargará de entregar los mensajes correspondientes a cada
cliente, de manera que a pesar de no tener conocimiento de lo que sucede en los
escenarios decisorios experimentales tendrá la capacidad de dar seguimiento a los
58
cambios en los parámetros que sean definidos para cada uno de los escenarios decisorios
experimentales.
• Podremos reducir la carga de datos en el intercambio de información cliente hacia el
servidor y viceversa, esto lo haremos usando como mensaje un objeto JSON,
asegurándonos de transmitir lo estrictamente necesario para poder mantener el estado en
los clientes sincronizado y coordinado por el servidor, esto reduce la carga de datos a
solicitudes de algunos cuantos Kilobytes de tamaño como máximo ya que nos
aseguraremos de transmitir solo la información necesaria, recordemos que existirá un
retraso en la respuesta de alrededor de 500 ms que es el tiempo que hemos decidido sea
el que existe entre cada petición realizada por los clientes, con esto el ancho de banda
requerido se reduce a 5 Kilobytes por segundo.
La implementación con los ajustes anteriores mencionados quedará de la siguiente manera.
Figura 24 - Ajustes de implementacion MVVM Fuente: diseño propio
59
Teniendo en cuenta los puntos expuestos anteriormente para realizar los ajustes correspondientes
en la implementación del escenario decisorio experimental en cuestión, a continuación
presentamos los resultados obtenidos.
Resultados
Como ya lo mencionamos no estamos entrando en el detalle técnico de la implementación nos
limitamos a dar una explicación técnica somera, nos enfocamos en los problemas y soluciones que
se tuvieron para poder llegar a un modelo general, en este apartado nos centramos en describir
los resultados obtenidos después de que realizamos los ajustes planteados anteriormente y que
consideramos aceptable el resultado obtenido del desarrollo técnico de este escenario decisorio
experimental como un primer acercamiento al objetivo que busca nuestro trabajo.
Almacenamiento
En cuanto a la parte del almacenamiento de la información obtenida, planteamos inicialmente que
toda la información que fuese obtenida de la experimentación, sería almacenada en una sola tabla
que guardara el detalle como documentos XML, lo cual al principio parecía buena idea, aunque
más tarde se descubrió que esta implementación no era la más óptima para el resultado que
esperábamos obtener que consiste en la explotación de la información obtenida a partir de la
experimentación, esto lo veremos más a detalle en el capítulo cinco, ya que llegamos a esta
conclusión después de haber realizado nuestro primer implementación como acercamiento
basándonos en el escenario decisorio experimental del Ultimátum.
Hasta el momento y como resultado del primer acercamiento los datos tenemos de salida de la
experimentación que puede ser realizada, es un documento XML con los detalles de la interacción
llevada a cabo por los participantes en cada uno de los eventos del escenario decisorio
experimental realizados.
Lógica
Debido al cambio que implementamos en el patrón de programación de nuestro escenario lógico,
esto es el uso de MVVM, toda la lógica del escenario decisorio experimental quedó escrita en
código JavaScript que se ejecuta de lado de los clientes, por lo tanto nos hemos ahorrado el
problema que teníamos al inicio que consistía en generar código Java para que fuera ejecutado en
60
el servidor, almacenarlo y obtenerlo de manera dinámica al ser requerido por un evento de un
escenario decisorio experimental. Este cambio además nos ayuda a mejorar el desempeño del
sistema de lado del servidor como del lado de los clientes.
Entonces la lógica queda almacenada como texto plano que será ejecutado como un script de
JavaScript en el navegador de los clientes. Este cambio, nos ha facilitado muchísimo la
implementación del modelo lógico y la interacción con los clientes en la vista gracias a las
propiedades observables que pueden ser implementadas usando el patrón MVVM, lo cual hicimos
utilizando el framework Knockout.js
Presentación
Además de habernos facilitado la implementación del modelo lógico, el uso del patrón MVVM
también nos facilita la presentación del escenario decisorio experimental, ya que solamente se
definen los componentes que son requeridos a nivel presentación y su comportamiento es
asociado directamente con el modelo lógico del escenario decisorio, lo cual nos hace más fácil la
implementación ya que parta del código que se utilizaba para el control de la presentación del
escenario en los clientes se reduce utilizando este patrón, y prácticamente la capa de presentación
se reduce a una página HTML que es controlada lógicamente por el modelo implementado, todo
esto o directamente en el cliente.
Comunicación
El aspecto de comunicación como ya lo hemos mencionado, fue cubierto utilizando la técnica http
pull, a continuación explicaremos como este mecanismo fue aplicado para satisfacer las
necesidades del maestro escenarios decisorio experimental.
En primera instancia el servidor provee ambos clientes de una página completa que incluye todos
los recursos necesarios para la presentación del escenario decisorio experimental, esto es,
presenta a cada uno de los clientes la vista del escenario en el momento inicial, posteriormente
cada uno de los clientes inicia las peticiones de actualización de estado correspondientes, en el
primer resultado obtenido cuando estábamos haciendo uso del patrón MVC, cada una de estas
peticiones de actualización de estado por parte de los clientes implicaba que el código completo o
de la página fuera transmitido hacia el servidor y como respuesta, el servidor regresaba
nuevamente la actualización de la página con los cambios de acuerdo al estado del escenario
61
decisorio experimental, esto implica una carga de datos bastante alta lo cual consideramos un
desperdicio de recursos computacionales tanto en el servidor como en los clientes.
Después del cambio de patrón de MVC a MVVM, buena parte del código tuvo que ser
implementada nuevamente, y como ya lo hemos adelantado la parte de ejecución del modelo
lógico del escenario decisorio experimental queda totalmente de lado del cliente, por lo tanto en
primera instancia el servidor provee una página completa a cada uno de los clientes la cual es
capaz de presentar el escenario decisorio experimental de acuerdo al estado que comunique el
servidor por cada solicitud de actualización de estado en el cliente, esto es cada uno de los clientes
solicita el estado del escenario decisorio en cuestión, el modelo recibe la actualización de estado
desde el servidor y la vista se actualiza de manera automática de acuerdo a los cambios que se
registren en el modelo, de esta forma llegamos a la conclusión que el servidor no necesita tener
una réplica del estado del modelo decisorio experimental es suficiente con que sea capaz de dar
seguimiento a los datos que recibe desde los clientes, mientras que los clientes reciban las
actualizaciones de estado desde el servidor podrán replicar el estado actual del escenario
decisorio experimental, esto reduce la complejidad de la implementación.
Una vez que hemos realizado la implementación el escenario decisorio experimental “Ultimátum o
el dictador”, llevaremos nuestro conocimiento adquirido hacia la implementación en el sistema de
forma que podamos modelar escenarios de manera más sencilla, aprovechando las funciones y
características que hemos desarrollado en la implementación del escenario decisorio experimental
antes mencionado, el objetivo es generalizar los mecanismos de almacenamiento de datos, de
lógica, de presentación y de comunicación.
Generalización del modelo de implementación
Hasta ahora hemos realizado la implementación ad hoc de un escenario decisorio experimental,
pero esto ha sido solamente un acercamiento al resultado que deseamos obtener. Hasta el
momento hemos encontrado problemas técnicos en la solución del escenario decisorio
experimental anterior, que hemos solventado con funcionalidad específica, ahora el verdadero
reto consiste en convertir esta solución ad hoc, en una solución general que pueda presentar
cualquier escenario decisorio experimental que se modele, usando los mecanismos de
presentación, lógica, datos y comunicación que hemos desarrollado y los cuales generalizaremos
de manera que podamos obtener datos relevantes para su posterior análisis.
62
Una vez que hemos realizado la implementación de un escenario decisorio experimental y debido
a que desde el principio planteamos llegar a una solución general, durante el desarrollo ad hoc del
primer acercamiento hemos obtenido algunas ideas para el desarrollo de esta implementación y
como le hemos realizado en el primer acercamiento los dividiremos en cuatro puntos principales
que consideramos pueden constituir la base para esta implementación general.
La razón por la que hemos decidido dividir la implementación en estos cuatro componentes
principales consiste en que durante el desarrollo del primer acercamiento llegamos a la conclusión
que esta separación del sistema resultaría óptima para los fines requeridos los cuales a nivel
técnico pueden ser satisfechos de la siguiente manera.
Almacenamiento
En primer lugar y como ya lo hemos hecho para la implementación de nuestro primer
acercamiento a la solución tenemos el problema del almacenamiento, pero ¿A qué nos referimos
con almacenamiento en términos de un escenario decisorio experimental?
En primer lugar tenemos que ser capaces de almacenar la información del escenario decisorio
experimental lo cual es su nombre, descripción, características, lógica y presentación.
Posteriormente también debemos poder generar instancias parametrizadas de estos escenarios
decisorios experimentales para que puedan ser utilizadas en experimentos. Y por último cuando
estas instancias sean consumidas debemos ser capaces de almacenar la información obtenida de
la experimentación por cada una de las instancias generadas.
En la primer parte de la necesidad, no observamos mayor problema esto bien se puede almacenar
en una tabla de base de datos que contenga la información del escenario decisorio experimental,
nombre, descripción y características (número de participantes, indicar si requiere moderador,
etc.).
Por otro lado definir un repositorio de datos donde podamos almacenar la lógica y la presentación
en principio resultaba poco complejo, este problema fue mitigado en parte por el cambio que se
realizó en el patrón de desarrollo, esto lo explicaremos en el apartado de lógica por el momento
diremos que bastaron campos de texto para almacenar esta información.
63
En el caso de los datos obtenidos por la experimentación como sabemos, no es posible generar un
modelo estandarizado de datos para almacenar la información de diferentes escenarios decisorios
experimentales, la idea inicial y que se conserva hasta este momento es guardar esta información
en archivos XML que contengan el detalle de la experimentación realizada en los escenarios
decisorios experimentales. Esta solución puede parecer insuficiente y en verdad lo es, se encontró
una solución posteriormente a lo largo del desarrollo que presentaremos en el capítulo siguiente
de que forma parte de la obtención de resultados.
Lógica
Nuevamente el patrón MVVM nos ha sido de gran ayuda para el desarrollo de este trabajo, como
parte de los beneficios que obtuvimos alcanzar su implementación pudimos mejorar la
implementación del modelo lógico eliminando la necesidad de que el servidor estuviese
involucrado en el desarrollo del escenario decisorio experimental esto quedó como un proceso
totalmente concerniente a los clientes donde el servidor funge como el coordinador de las
operaciones que se llevan a cabo entre los clientes de esta forma optimizamos los recursos
computacionales disponibles, redujimos el costo en complejidad del sistema y facilitamos la
implementación requerida para satisfacer las necesidades de nuestro trabajo.
Inicialmente debíamos encontrar una manera para almacenar la lógica o en términos informáticos
el programa que controla el modelo del escenario decisorio experimental, recordemos que al
inicio planteamos que la solución que se le podía dar a este problema era: generar archivos jar,
por cada uno de los escenarios decisorios experimentales, posteriormente serializar estos archivos
en formato binario para guardarlos en un campo de tipo BLOB en la base de datos, de forma que
cuando fuese necesario recuperarlos, se obtuviera la información binaria desde la base de datos,
se cargará dinámicamente en sistema principal y fuera ejecutado para llevar el control de una
instancia de un escenario decisorio experimental. Todo esto no solamente suena complicado, en
verdad lo es, afortunadamente no tuvimos que llevar a cabo esta implementación, MVVM nos ha
facilitado el desarrollo de nuestra aplicación, y en este caso también nos ha ayudado, ya que la
lógica del modelo del escenario decisorio experimental se genera como un script que se ejecutará
en el navegador de los clientes y es mucho más fácil almacenar un script en un campo de texto de
la base de datos por lo tanto no requeriremos de mayor complicación que simplemente escribir y
leer tal campo.
64
Presentación
En la parte de la presentación no hay mucha diferencia en cuanto la parte de la lógica, gracias a la
implementación de MVVM un aspecto más que nos ha facilitado es la parte de la presentación, ya
que a diferencia de MVC con MVVM no hubo necesidad de realizar una implementación por
separado de la lógica de la vista esto es el escenario presentado en el cliente, simplemente se
asocian los controles que son usados en la presentación directamente al modelo lógico del
escenario, esto nos permiten además de facilitar la implementación, mejorar el desempeño del
sistema aprovechando las capacidades de cómputo de los clientes para presentar el escenario,
mientras que el servidor simplemente se encarga de coordinar la entrega de mensajes a los
clientes conectados.
Por lo tanto la parte de la presentación se reduce a una página HTML que tendrá los elementos
necesarios para presentar el escenario decisorio experimental en cuestión.
Debido a la naturaleza propia de los diferentes escenarios decisorios experimentales, cada una de
las páginas requeridas para ellos deberá ser diseñada específicamente para presentar el escenario
decisorio experimental deseado.
Comunicación
Por último y como parte crucial del sistema tenemos la implementación de la comunicación, como
ya lo hemos mencionado la comunicación se llevó a cabo usando http pull, para ello desarrollamos
métodos específicos adaptados para el escenario decisorio experimental Ultimátum o el dictador,
los cuales encargan de realizar las siguientes funciones:
Método Tipo Función
requestEstatus Petición Solicita actualización del estado del escenario al servidor
setEstatus CallBack Realiza la actualización de estatus en la instancia local del escenario
decisorio (turno, oferta, vista de controles)
Tabla 6 - Funciones de comunicación cliente Fuente: diseño propio
65
Método Tipo Función
getEstatus Petición Obtiene el último estado de la instancia del escenario en cuestión de
acuerdo a la petición realizada por el cliente.
setEstatus Respuesta
http
Transforma la respuesta del estado del escenario decisorio
experimental a un objeto que pue ser serializado y transmitido sobre
http para así llegar al cliente
Tabla 7 - Funciones de comunicación servidor Fuente: diseño propio
En las tablas anteriores podemos observar que el proceso de comunicación se reduce a las
funciones descritas, las cuales están casi listas para su implementación en un modelo general,
solamente que en la implementación del escenario decisorio experimental ultimátum, están
diseñadas para transmitir la información referente exclusivamente a este escenario, para que se
puedan implementar de forma general, el ajuste requerido consistió en permitir que el servidor
pudiera serializar cualquier tipo de objeto esto fue implementado aplicando socialización de tipo
JSON a los objetos de estado de los escenarios decisorios experimentales.
Resumen
A manera de un breve resumen tenemos que la generalización del modelo de implementación
consiste en:
• Almacenamiento
o Almacenar información de los escenarios decisores experimentales
o Almacenar la lógica del escenario decisorio experimental
o Almacenar la presentación del escenario decisorio experimental
o Almacenarlo resultados de la experimentación
• Lógica
o No existe implementación en el servidor
o Se almacena como una cadena de texto que es un script que se ejecutará de lado
del cliente
• Presentación
o Será una página HTML que se almacenará como una cadena de texto
66
• Comunicación
o Se utilizará el servidor solamente como coordinador de estado de los escenarios
decisores experimentales
o Los clientes comunicarán las actualizaciones de estado al servidor
o Los clientes solicitarán las actualizaciones de estado al servidor
En el siguiente diagrama podemos apreciar los ajustes requeridos para la generalización de la
solución para cualquier escenario decisorio experimental.
Figura 25 - Modelo general de implementación MVVM Fuente: diseño propio
Como podemos apreciar en la Figura 25, no hay mucho cambio con respecto a la implementación
del escenario decisorio Ultimátum, aquí observamos claramente que la implementación lógica y
visual del modelo del escenario decisorio experimental queda totalmente del lado del cliente y
como ya lo habíamos alcanzado a notar el servidor cumple la función de permitir que los clientes
intercambian mensajes para que así cada uno de ellos tenga la información del escenario decisorio
67
experimental actualizada de manera que la representación del escenario decisorio experimental
este en todo momento actualizada en los clientes, con esto se cumple que los clientes puedan
interactuar entre ellos y el escenario decisorio experimental, y por otro lado el servidor al fungir
como coordinador de los mensajes que se intercambian puede dar seguimiento a la evolución de
los experimentos realizados con los escenarios decisorios experimentales observando las
propiedades que se definan para ellos.
68
CAPÍTULO IV RESULTADOS OBTENIDOS
En el capítulo anterior, hemos visto como fue llevada a cabo la implementación del modelo
propuesto, nos encontramos con impedimentos de tipo técnico y lógico, por lo cual tuvimos que
adaptar la solución para poder satisfacer la necesidad planteada como parte de la propuesta
presentada.
En el presente capitulo describiremos los resultados obtenidos después del desarrollo de la
propuesta realizada como parte de este trabajo, incluiremos además el detalle de los últimos
ajustes que realizamos como parte de la explotación de los datos obtenidos por la
experimentación con el sistema, ya que como lo hemos mencionado la propuesta inicial y el
desarrollo se han quedado un poco cortos hasta el momento de la implementación, y hemos caído
en cuenta que puede existir una mejor solución para este problema lo cual no alcanzamos a cubrir
en el desarrollo de este trabajo.
Implementación del modelo general
Como parte el desarrollo generamos un primer acercamiento al problema, esto fue basándonos en
el escenario decisorio experimental del ultimátum, este primer acercamiento nos ha servido para
sentar las bases sobre las cuales definimos el modelo general anteriormente expuesto como parte
del desarrollo, antes de ese momento sólo podríamos decir que la implementación era ad hoc,
pero ahora que hemos propuesto una generalización de este modelo procederemos a realizar la
implementación de este modelo.
De manera similar al capítulo anterior no profundizaremos en el detalle técnico de la
implementación de este modelo, nos limitaremos a definir cuáles fueron los aspectos cubiertos,
como se llevó a cabo y cuál es la manera en que los escenarios decisorios deberán ser modelados
para poder llevar a cabo su implementación.
Como lo hemos expuesto en la generalización del modelo de implementación dividimos la
implementación de nuestro sistema en cuatro bloques en los cuales proponemos una solución de
generalización o para el modelo de implementación de los escenarios decisorios experimentales.
En el capítulo anterior hemos propuesto la generalización del modelo de implementación para
cualquier escenario decisorio experimental, pero ¿Cómo ha sido realizada esta generalización?
69
Esto lo describiremos en este apartado mencionando de forma breve y a manera de resultado ya
que no entraremos en el detalle técnico que implicó el desarrollo.
Figura 26 - Modelo solución general
Fuente: diseño propio
En la figura anterior plasmamos en forma de esquema como fue realizada la implementación
general del modelo propuesto, de manera rápida la implementación general se realizó de la
siguiente manera.
Almacenamiento
Para el almacenamiento de los datos referentes al escenario decisorio experimental como nombre,
características, descripción. Mientras que la parte de lógica y vista fueron almacenados en sendos
campos de texto. En este punto no existió mayor complicación simplemente se agregó una tabla
de detalle para la lógica y la vista de los escenarios decisorios experimentales.
Lógica
La lógica de los escenarios decisorios experimentales es controlada por un script que se ejecuta en
el navegador del cliente el cual es código JavaScript. Para la implementación general del modelo se
creó o un script base del cual se debe extender la funcionalidad para realizar la implementación
del modelo deseado el cual se presenta a continuación.
70
Como observamos en la figura anterior el modelo base se compone de cuatro propiedades:
• evento
Esta propiedad sirva para almacenar el identificador del evento en el cual se está
participando se utiliza cada vez que un mensaje es enviado al servidor para indicarle cual
es el evento al que pertenece el mensaje.
• rol
Esta propiedad almacena el rol que tiene el usuario en el escenario decisorio experimental,
se utiliza para que la lógica pueda llevar a cabo las operaciones necesarias de acuerdo a la
participación que puede tener el usuario en cierto o escenario decisorio experimental,
sirve como una variable de control para decir que acciones puede realizar usuario y en qué
momento.
• turno
De manera análoga a la propiedad rol la propiedad turno es una variable de control que
permite identificar en qué momento el usuario puede tener interacción con el escenario
decisorio experimental, esto sirve para presentar elementos de control en la pantalla del
usuario, mensajes, etc.
• estado
De manera similar esta propiedad permite identificar el estado que tiene el escenario
decisorio experimental en algún momento, es actualizada constantemente de acuerdo a
las respuestas del servidor por las peticiones realizadas al status de la instancia en la cual
se está participando.
Estas son las propiedades que se requieren en el modelo base que sirve para modelar los
escenarios decisores experimentales, como observamos todas ellas sirvan de control para el
71
estado del escenario decisorio experimental. Las propiedades adicionales requeridas para cada
uno de los escenarios decisorios experimentales se definen de manera similar como variables de
tipo observable, de esta forma al realizar una interacción con ellas el estado se reflejará
inmediatamente en la representación visual del cliente y se comunicará inmediatamente al
servidor por lo que los demás clientes estarán enterados del cambio y realizarán las
modificaciones necesarias en su instancia de manera que así logramos la sincronización del estado
del escenario decisorio experimental en los diferentes clientes, y también comunicamos los
cambios que deseamos observar al servidor quien se encargará de llevar el registro de estos
cambios.
Ahora tenemos los métodos:
• startEscenario
Este método será el responsable de dar inicio a una instancia de un escenario decisorio
experimental, realizará el cambio correspondiente en el estado y notificará al servidor que
el escenario ha sido iniciado, de esta forma todos los clientes conectados al escenario
decisorio experimental serán notificados que deben ejecutar el mismo método y así iniciar
con la experimentación
• endEscenario
De manera similar al método anterior, este método será el responsable de indicar que un
escenario ha finalizado, realizará el cambio correspondiente en el estado y notificará al
servidor que el escenario ha sido finalizado, así los demás clientes obtendrán la
actualización del estado del escenario decisorio experimental en el momento que realicen
su próxima petición de actualización de estado, a lo cual el servidor les indicará que
ejecuten la misma función terminando de esta forma el escenario en todos los clientes
conectados a él
• executeAction
Este método se ejecutará cada vez que un cliente reciba una notificación de actualización
de estado, la cual puede incluir actualizaciones en las propiedades específicas de cada
escenario decisorio experimental, esto puede ser alguna cantidad, algún tuno, algún texto,
o bien otra propiedad o elemento del escenario decisorio experimental, de manera que
los mensajes que son recibidos desde el servidor como respuesta a las peticiones
72
realizadas por los clientes de actualización de estado incluyen información acerca de cómo
actualizar el estado local de la instancia del escenario decisorio experimental.
Además de los métodos mencionados, cada escenario decisorio experimental puede incluir
métodos propios que requiera como parte del modelo del escenario decisorio experimental, esto
es para que pueda llevar a cabo el funcionamiento lógico requerido por cada escenario decisorio
experimental diferente, esto puede ser cambiar turno a los participantes, modificar alguna
cantidad, modificar alguna descripción o modificar cualquier elemento del escenario decisorio
experimental.
Presentación
En la parte de la presentación no se presenta mayor complicación esta parte de la implementación
queda resuelta como una página HTML en la cual se presentan los elementos necesarios del
escenario decisorio experimental, estos pueden ser texto, botones, controles, imágenes u otro
elemento que pueda inclusive audio o video.
Para el control de la presentación se realiza directamente al modelo lógico del escenario decisorio
experimental permitiendo de esta forma que el control lógico de la presentación sea el “reflejo”
del estado actual del escenario decisorio experimental.
Comunicación
En la implementación que realizamos para el primer acercamiento definimos un conjunto de
métodos que controlan la comunicación tanto en el cliente como en el servidor estos los podemos
encontrar en las Tabla 6 y Tabla 7.
Tales métodos son suficientes y satisfacen la necesidad para todos los escenarios decisorios
experimentales, el ajuste requerido para hacer la implementación con MVVM fue por la parte del
cliente notificará solamente de los cambios en la instancia del escenario decisorio experimental
mas no todos los cambios en la página, y por parte del servidor regresar solamente la información
requerida para que los clientes pudiesen realizar la actualización de sus instancias locales del
escenario decisorio experimental esto tuvo sus complicaciones a nivel técnico que no
mencionaremos a detalle solamente diremos que se redujeron a la serialización de los objetos de
datos en formato JSON, para que así puedan ser consumidos directamente por los clientes.
73
Integración
Hasta el momento nos hemos enfocado en la creación de un modelo general para poder llevar a
cabo experimentos con escenarios decisorios experimentales, pero no hemos presentado un
sistema integral que nos permita llevar a cabo todo el proceso desde la definición de los
escenarios decisorios experimentales, la creación de las instancias parametrizadas, el ingreso de
los participantes y por último la obtención de los resultados de esta experimentación.
Precisamente en este apartado mencionaremos como es que proponemos la integración del
corazón de nuestro trabajo en un sistema que permita llevar a cabo todas las tareas mencionadas
anteriormente.
Hablar de todo el detalle de la integración en un sistema informático que abarque todo el proceso
necesario para la implementación es un tema amplio por lo tanto no lo mencionaremos a detalle
bastará con que mencionemos cuales fueron los módulos necesarios, la propuesta para incluir
algunos adicionales y cuáles la propuesta que se ha realizado con el fin de tener un sistema
funcional que soporte la operación de nuestro trabajo.
Módulo Experimentos
En este módulo se presentan los escenarios decisorios experimentales, disponibles dentro del
sistema los cuales ya han sido modelados están disponibles para generar eventos de ellos en los
cuales se pueda participar para obtener información de experimentación real.
Este módulo presenta la información dentro de categorías donde organizamos los escenarios
decisorios experimentales, dentro de cada una de las categorías podremos encontrar los
escenarios decisorios experimentales disponibles al seleccionar una categoría deseada, una vez
que seleccionamos un escenario decisorio experimental dentro de la categoría señalada, se
mostrará la información del escenario decisorio experimental seleccionado esto es nombre,
descripción y características.
74
Figura 27 - Módulo Experimentos
Fuente: diseño propio
Este módulo solamente muestra la información de los escenarios decisorios experimentales, pero
una propuesta a la cual no pudimos llegar consiste en que dentro de este módulo se puedan crear
los escenarios decisorios experimentales esto es, que se pueda capturar la información nombre,
descripción, características y también se pudiera modelar el experimento tanto la presentación
como la parte lógica, este es un trabajo complejo el cual no pudimos completar por falta de
tiempo, sabemos que su implementación es viable y le daría auto suficiencia al sistema ya que con
esto se evitaría la necesidad de que exista alguien que modele el escenario decisorio experimental.
Módulo Eventos
En este módulo se presentan los eventos disponibles para experimentación en el sistema, cuando
decimos evento nos referimos a una instancia de un escenario decisorio experimental dentro del
sistema, a diferencia del módulo anterior, aquí es necesario poder crear una instancia de un
escenario decisorio específico bajo ciertos parámetros, lo cual sí es posible.
75
Al ingresar a este módulo vamos a observar que se parece bastante al módulo Experimentos, y nos
muestra de manera similar la información referente a los experimentos, primero una agrupación
en categorías, donde al seleccionar una categoría se mostrarán los experimentos disponibles
dentro de ella y al seleccionar un escenario decisorio experimental se mostrará el detalle de este,
además de los eventos que han sido creados para tal escenario decisorio experimental.
Figura 28 - Módulo Eventos
Fuente: diseño propio
En la parte superior de la lista donde aparecen las instancias creadas existe un botón que permite
crear una nueva instancia del escenario decisorio experimental seleccionado, donde podremos
establecer los parámetros de inicio de tal escenario de tal forma que cada una de las instancias
pueda tener características diferentes al momento de su inicio, tales características corresponden
a las variables definidas como propiedades o elementos del escenario decisorio experimental y el
objetivo es observar el cambio en los resultados de acuerdo a la parametrización de los eventos
generados para los escenarios decisorios experimentales.
76
Módulo Participar
Este módulo permite a un usuario participante ingresar a los eventos de los escenarios decisorios
experimentales que han sido generados en el módulo eventos, aquí se mostrarán todos los
eventos disponibles y se tendrá la opción de unirse al evento deseado.
Figura 29 - Módulo Participar
Fuente: diseño propio
Una vez que el usuario participante haya seleccionado la opción de unirse a un evento se
presentará un mensaje que le indicará que espere hasta que el escenario pueda ser iniciado, una
vez que esto suceda se mostrará un botón con la leyenda iniciar que permitirá a cualquier a los
participantes conectados dar inicio al evento en cuestión, al hacer clic un usuario en tal botón el
mensaje de inicio se transmite a todos los clientes, iniciando la instancia de manera simultánea en
todos los clientes.
Ya veremos el proceso completo más adelante para cada uno de los escenarios decisorios
experimentales que han sido implementados.
77
Módulo Análisis
Este módulo presenta los resultados obtenidos de la experimentación realizada en los escenarios
decisorios experimentales, tiene una organización similar al módulo de experimentos y eventos, a
diferencia que en este módulo se obtendrá el resultado de los experimentos al seleccionar
escenario decisorio experimental.
El detalle de los experimentos está compuesto por dos partes la primera en la que se presentan
los resultados de los eventos de los escenarios decisorios experimentales y unas gráficas que
reflejan estos resultados del conjunto de experimentos realizados.
Figura 30 - Módulo de Análisis (Escenario Decisorio)
Fuente: diseño propio
La segunda parte consiste en el detalle de cada uno de los eventos de experimentación que se han
realizado para los escenarios decisorios experimentales, al seleccionar cada uno de los eventos se
tendrá el detalle de acuerdo la definición que se realice para cada uno de los escenarios decisorios
experimentales.
78
Figura 31 - Módulo Análisis (Evento)
Fuente: diseño propio
En la Figura 30 y la Figura 31, observamos el resultado de un análisis realizado al escenario
decisorio experimental ultimátum, en las figuras observamos el resultado final después de un
ajuste realizado en explotación de los resultados para que estas gráficas que mostramos puedan
posible de generar de manera más sencilla, explicaremos esto más a detalle adelante.
Escenarios decisorios experimentales
Después de la implementación realizada para la generalización de la propuesta que hemos
desarrollado, lo que nos queda por exponer es cómo se aplica a más de un escenario decisorio
experimental que es el fin de este trabajo, por lo tanto en este apartado describiremos de manera
breve los resultados obtenidos en cuanto a la implementación de otros escenarios decisorios
experimentales que fueron contemplados como parte del desarrollo de este trabajo.
79
Mencionaremos de forma breve, en qué consisten cada uno de estos escenarios decisorios
experimentales y como fueron implementados en el marco de nuestro sistema bajo la propuesta
que hemos realizado, veremos el resultado de su implementación.
Ultimátum o el dictador
Es un experimento que intenta cuantificar el egoísmo fue diseñado por los economistas Güth,
Werner, Schmittberger y Schwarze con el fin de posibilitar el estudio cuantitativo de la
cooperación y el altruismo de la conducta humana.
En este experimento participan dos jugadores cada uno desempeña un papel diferente uno se
denomina moderador y el otro participante. El experimentador ofrece una cantidad de dinero que
tienen que repartir del siguiente modo el moderador decide cómo se reparte, es decir, que
propone el reparto que se le antoje, por ejemplo como 80 para él y 20 para el otro jugador. Pero
es este último quien decide aceptar o rechazar la propuesta de reparto si la acepta cada uno se
lleva la cantidad propuesta.
Éste escenario ya lo hemos analizado extensivamente a lo largo del desarrollo del trabajo por lo
cual nos limitaremos al presentar los resultados obtenidos de la implementación.
Figura 32 - Implementación de ultimatum
Fuente: diseño propio
80
En la Figura 32 observamos el flujo que se sigue en el sistema en el caso del escenario decisorio
experimental ultimátum
El experimento del tranvía
Es un experimento mental ético ideado por Philipp Foot y analizado extensamente por Judith
Jarvis Thomson y, más recientemente, Peter Unger.
No existe interacción entre los participantes, se les presenta el caso y cada quien responde.
Consiste en lo siguiente:
Un tranvía corre fuera de control por una vía. En su camino se hallan cinco personas atadas a la vía
por un filósofo malvado. Afortunadamente, es posible accionar un botón que encaminará al
tranvía por una vía diferente, por desgracia, hay otra persona atada a ésta. ¿Debería pulsarse el
botón?
En este caso, se presenta la narración de la historia, y posteriormente se realiza la pregunta de la
decisión que debe tomar el participante.
81
Figura 33 - Diagrama de flujo Experimento del tranvia
Fuente: diseño propio
En este caso se requiere tener el control de la presentación que se realiza para que el usuario
tenga conocimiento de la situación, aquí mediremos el tiempo que tarda el participante en tomar
la decisión y sea su respuesta fue positiva o negativa.
La implementación en sistema queda de la siguiente manera:
82
Figura 34 - Implementación experimento del tranvia
Fuente: diseño propio
El efecto del anclaje
En este experimento no hay interacción entre los participantes tienen que capturar un dato de
alguna cantidad o dígito (número telefónico o algo similar) y después realizar una estimación de
una cantidad no conocida. Se pretende medir como el efecto “contamina” nuestra opinión sobre
las cosas mediante información periférica e irrelevante como ocurre en la vida cotidiana ya que es
una pauta muy corriente del comportamiento humano y que utilizamos más a menudo de lo que
nos damos cuenta.
83
Este experimento fue propuesto por el psicólogo Gary Marcus consiste en:
Se presenta a los participantes una pregunta a la que deben responder con una cantidad, pero
previamente se les ha puesto a pensar en una cantidad que puede influenciar en la respuesta que
proporcionen para el experimento.
Una de las preguntas que comúnmente se presentan para este escenario es la siguiente:
Sume 400 a los tres dígitos de su número telefónico, una vez realizada la operación, contesten la
siguiente pregunta ¿en qué año terminaron por fin los saqueos de Atila, rey de los hunos, en
Europa?
El diagrama de flujo para este escenario queda como se muestra a continuación.
84
Figura 35 - Diagrama de flujo Efecto del anclaje
Fuente: diseño propio
La implementación en el sistema queda de la siguiente forma.
85
Figura 36 - Implementación Efecto del anclaje
Fuente: diseño propio
Los amantes de Catherine
También conocido como arrogancia epistémica, o literalmente como nuestra arrogancia
concerniendo en los límites del conocimiento. Consiste en:
Elegir un numero aleatoriamente, el cual puede corresponder a cualquier cosa: la proporción de
corredores de bolsa en Ucrania Occidental, las ventas de algún libro durante los meses con r en
ellos, el IQ promedio de los editores de libros de negocios (o escritores), el número de los amantes
de Catherine II de Rusia, etc. Pedir a cada participante estimar un rango posible de valores para
ese número de tal forma en la que ellos crean que tienen un 98% de probabilidades de acertar y
2% de fallar. En otras palabras lo que se está adivinando.
El diagrama de flujo de este escenario decisorio experimental es muy parecido al anterior y se
presenta a continuación.
86
Figura 37 - Diagrama de flujo Amantes de Catherine
Fuente: diseño propio
La implementación en el sistema queda de la siguiente forma
Figura 38 - Implementación Amantes de Catherine
Fuente: diseño propio
La imagen borrosa
Consiste en mostrar a dos grupos de personas una imagen borrosa de un hidrante suficientemente
borrosa para que no pueda reconocerse el objeto que es. Para un grupo incrementar la resolución
lentamente en diez pasos. Para el segundo hacerlo más rápido en cinco pasos. Detenerse en el
punto en el que ambos grupos se les ha presentado una imagen idéntica y pregunten qué es lo
que ellos ven.
87
En nuestro casó consistiría en generar instancias con diferentes parámetros para que se
comporten de una u otra forma de acuerdo a lo requerido.
El diagrama de flujo para este escenario decisorio experimental es el siguiente
Figura 39 - Diagrama de flujo Imagen Borrosa
Fuente: diseño propio
La implementación en el sistema queda de la siguiente forma
88
Figura 40 - Implementación Imagen borrosa
Fuente: diseño propio
Análisis de resultados
Para poder realizar el análisis los resultados, caímos en cuenta que la primer propuesta realizada la
cual consistía en almacenar la información de los resultados como archivos XML en campo de
texto de la más de datos no era la solución óptima para esta necesidad por lo cual tuvimos que
replantear esta solución que la solución inicialmente propuesta e implementada tenía las
siguientes deficiencias que complicaban en grado excesivo y por más soluciones que tratamos de
dar al análisis de resultados simplemente no era posible si teníamos la información almacenada de
esta forma.
• La información de resultados era difícil de analizar de manera directa, se debía obtener
documento XML, para descomponerlo y así obtener el detalle de los resultados por evento.
• Era necesario generar un parser para cada uno de los escenarios decisorios
implementados en el sistema
• El análisis requerido usando la implementación de un documento XML resultaba además
de compleja excesivamente costosa en términos computacionales ya que se requerían
muchas operaciones para extraer la información requerida de los resultados
Teniendo en cuenta los puntos anteriores y después de mucha experimentación para la obtención
de las gráficas de resultados a partir de los documentos XML, se llegó a la conclusión que esto no
89
resultaría viable, por lo cual tuvimos que comenzar a idear otra alternativa como solución a este
problema.
Después de varios experimentos y de replantear un poco la solución requerida para satisfacer esta
necesidad de la manera más viable posible, nos encontramos una solución que no se nos ocurrió al
inicio, pensamos que esto se debió al hecho que estábamos convencidos de que se podría llegar a
un modelo de datos el cuál permitiera almacenar la información obtenida de los resultados de los
experimentos realizados y además nos permitiera explotarla de forma sencilla, para lo cual se
concluye que esto no es posible.
En nuestro afán por intentar obtener una solución como fue planteada originalmente dejamos de
lado las características que nos ofrece el manejador de base de datos, ¿y cuáles son estas
características? Esto lo veremos como parte de la solución al problema que fue una mejora a la
propuesta inicialmente planteada.
Una mejora a la propuesta
Después de realizar innumerables pruebas para la obtención de un modelo que permitiera el
guardado y la explotación de la información resultante de la experimentación realizada con
nuestra propuesta caímos en la cuenta que el enfoque que teníamos era erróneo, simplemente no
es posible realizar una implementación de este tipo ya que cada uno de los escenarios decisorios
tiene diferentes necesidades de información y además cada análisis que quiera ser realizado
puede tener diferencias.
Y bien ¿cuál es la solución a la que se llega para este problema?, La solución que proponemos
como mejora a la propuesta inicial es la creación de una tabla en la base de datos la cual encaje
con las necesidades propias de cada uno de los escenarios decisorios experimentales modelados,
de esta manera se puede almacenar la información organizada de acuerdo a los parámetros que
se definan para los escenarios decisorios experimentales así el almacenamiento de la información
aunque resulta un poco más complejo, queda de una forma mejor organizada en la base datos
para su explotación.
No debemos pensar en la creación de estas tablas como algo estático que debe ser definido como
parte inicial de la implementación del sistema, aquí fue donde nuestra visión se quedó corta de
inicio ya que considerábamos la estructura de la base de datos como algo inmutable y como
90
sabemos no es así, el sistema bien puede tener la capacidad de aprovechar las bondades que
proporciona el manejador de base de datos para crear tablas que cumplan con las necesidades de
información de cada uno de los escenarios decisorios experimentales que pudieran generarse en
el sistema, así el almacenamiento de la información sería directamente en campos específicos
para cada una de las propiedades del escenario decisorio experimental que deseen ser analizadas,
como ya lo mencionamos esto mejora la organización de la información en el sistema y además
reduce la complejidad de la explotación de esta información a un query de SQL, los cuales también
se propone que se almacenen parte del detalle de los escenarios decisorios experimentales.
Esta solución descrita como una mejora no puede ser implementada del todo en el sistema
solamente se realizó la implementación para el escenario decisorio experimental del ultimátum,
esto se debe a que se requeriría que estuviera implementado el módulo para el alta de nuevos
escenarios decisorios experimentales, a pesar de esto explicamos a continuación como
realizaríamos la implementación de esta solución.
Figura 41 - Propuesta de implementación de mejora
Fuente: diseño propio
91
CONCLUSIONES
Cuando comenzamos con el desarrollo del presente trabajo nunca imaginamos que sería mucho
más difícil de lo que pensábamos, al inicio cuando pensamos que era un problema el cual no nos
llevaría mucho tiempo resolver, pero al enfrentarnos con las complicaciones que se presentaron
en primer lugar por limitantes tecnológicas, y después por la naturaleza del problema caímos en
cuenta que no era tan sencillo como pensábamos.
Con el modelo lógico del problema pensamos que avanzamos muy rápidamente ya que no hubo
muchos cambios con respecto al acercamiento inicial, pensamos en ello una y otra vez y llegamos
a la conclusión que el modelo propuesto como modelo general que puede describir cualquier
escenario decisorio experimental, resultaba en verdad sencillo y fácil de comprender, creemos que
en parte esto provocó que situáramos la complejidad del trabajo en un punto bajo (aquí vemos
como el efecto del anclaje fue aplicado en nosotros), lo cual provocó efectos tanto positivos como
negativos, dentro de los positivos podemos decir que iniciamos con mucho entusiasmo por llegar a
la solución que buscábamos. Por otro lado como un efecto negativo podemos decir que esto limitó
nuestra capacidad de análisis para el problema ya que teníamos en mente que se trataba de algo
“sencillo”.
Por otra parte el tema de la comunicación nos llevó bastante tiempo resolver, se debió haber
tenido en cuenta inicialmente las limitantes de la tecnología que sería usada en el servidor ya que
fue mucho el tiempo que dedicamos a tratar de hacer funcionar la primer propuesta de
comunicación usando Java, lo cual simplemente no fue posible y nos hubiese ahorrado valioso
tiempo de investigación y esfuerzo en pruebas, a pesar de ello conocimos nuevos enfoques que se
tiene para la comunicación de este tipo y cuáles son las ventajas y desventajas de una u otra
tecnología, en nuestro caso la desventaja fue la impuesta por los recursos disponibles para la
implementación en el servidor aunque hubiese sido ideal poder realizar su implementación.
En cuanto a la implementación lógica de los escenarios decisorios, inicialmente planteábamos que
el control fuera llevado por el servidor quien tendría conocimiento del estado del escenario en
todo momento, tardamos un poco en comprender que esto no era realmente necesario puesto
que quienes en verdad necesitaban tener conocimiento del estado del escenario eran los clientes
y no el servidor, creemos que estuvimos enfrascados en plantear la solución inicial por que nos
centramos en los beneficios que nos ofrecía Spring con AOP ya que ese fue el primer pensamiento
92
que vino a nosotros al plantear un escenario en el cual se tuvieran que realizar cambios sin
necesidad de modificar el código del servidor, salir de este marco y llegar a la conclusión que otro
planteamiento diferente era una buena opción nos llevó algo de tiempo y ya que habíamos
observado que con la primer solución era necesario realizar una implementación “duplicada” del
modelo lógico del escenario decisorio, esto era uno para el servidor y otro para los clientes, basta
darse cuenta que los clientes son quienes necesitan tener el conocimiento del estado del
escenario durante el desarrollo de la experimentación, de lo cual obtuvimos como resultado una
disminución en la complejidad del sistema en términos de implementación lógica y de
almacenamiento de información, nuevamente corroboramos el efecto de anclaje en la decisión
que tomamos por realizar la implementación como pensamos inicialmente sería la mejor opción
para reducir el esfuerzo.
Un tema adicional que no se menciona como parte del desarrollo de nuestro trabajo es la elección
del ambiente donde se llevará a cabo el desarrollo, tomamos poca importancia para este tema, e
iniciamos con un ambiente local en un equipo personal, posteriormente nuestro equipo sufrió
algunas dificultades técnicas y perdimos nuestro ambiente (afortunadamente no así nuestro
avance en el desarrollo), lo cual nos causó un poco de complicaciones en cuanto a tiempo.
Pensando en un escenario de este tipo a futuro, se contrató un servicio de hosting para nuestro
proyecto, con lo que no contábamos era que el servicio que fue contratado no contaba con las
mismas características con las que iniciamos el desarrollo de nuestro trabajo, el servicio tenía
versiones más viejas del servidor y de la JVM por lo que fue necesario realizar ajustes en la
implementación realizada hasta ese momento, afortunadamente en ese momento ya habíamos
realizado el cambio de MVC a MVVM y los cambios realizados fueron muy pocos, quedándonos
con un servlet del lado del servidor, este cambio fue relativamente sencillo porque prescindimos
de muchas de las características de las versiones de Java y Spring que estábamos usando
inicialmente. A diferencia de un escenario en el cual sea requerido realizar un proyecto de esta
naturaleza, se deberá verificar las características del servidor donde será hospedado y no a la
inversa como nos ha ocurrido para este proyecto.
Hemos cumplido con la implementación del prototipo de un sistema que permite realizar
experimentación con diferentes escenarios decisorios experimentales, que previamente fueron
definidos y modelados bajo la propuesta realizada como parte de este trabajo, cumplimos
también el objetivo de llevar a cabo la implementación de diferentes escenarios decisorios
93
experimentales usando nuestra propuesta y además la implementación fue posible también
realizar experimentación aunque de prueba sobre internet.
Este es un tema extenso y el tiempo no fue suficiente para realizar la implementación de todo lo
que inicialmente se tenía pensado, como sabemos esto sucede a menudo en el desarrollo de
proyectos informáticos ya que los esfuerzos se enfocaron en llevar a cabo la implementación del
modelo general que sirve de base para la implementación de los diferentes escenarios decisorios
experimentales sobre la propuesta que hemos realizado.
Estos son los puntos que no pudieron ser cubiertos en el desarrollo del trabajo pero que hubiesen
enriquecido de manera notable los resultados obtenidos también cabe mencionar que su
complejidad exigía mayor inversión de tiempo e investigación ya sea por complejidad o por
limitantes tecnológicas.
• Implementación de definición de parte visual del escenario decisorio experimental como
una página HTML sin tener que escribir código.
• Implementación de definición de modelo del escenario decisorio experimental mediante
una interfaz gráfica que permitiera la definición de este modelo usando bloques lógicos.
• Implementación de la mejora del almacenamiento de los resultados de la experimentación.
• Implementación de acceso a los eventos directamente por url
• Implementación de comunicación asíncrona usando Web Sockets (requería un cambio de
tecnología en el servidor a node.js)
Por último nos resta decir que este ha sido un trabajo de lo más complejo a lo que nos hemos
enfrentado hasta hoy ya que es un tema bastante amplio y siempre hay lugar para nuevas ideas y
mejoras a las soluciones propuestas.
94
ANEXOS
Anexo I – Comparación de MVC contra MVVM
Una pregunta reciente es la comparación que existe entre estos dos patrones, y bien si es que son
muy similares, MVVM es una mejora de MVC que implica ciertas “cosas” adicionales, a
continuación tenemos un diagrama que señala las principales diferencias entre MVC y MVVM.
Modelo Vista Controlador
Observamos directamente del diagrama que la entrada del usuario se dirige por el controlador, no
a la vista, esto quiere decir que el controlador está encargado de proveer la funcionalidad de
interacción.
Se pueden tener diferentes puntos de vista de acuerdo a la operación que se esté ejecutando, por
lo tanto, la entrada pasa por el controlador hacia la vista y hacia el modelo. Lo anterior permite
que la vista se encuentre aislada a cambio de que el controlador sea el enlace entre el modelo y la
vista, esto implica que el controlador tenga conocimiento tanto del modelo como de la vista lo
cual impone una limitante a la flexibilidad del patrón.
Modelo Vista - Vista Modelo
De inicio, la entrada del usuario es manejada por la vista quien a su vez contiene una referencia
del modelo pero el modelo no contiene información de la vista, de esta forma es posible una
relación de un modelo con diferentes vistas, ya que solamente se realiza una asociación entre la
vista y el comportamiento definido en el modelo, de esta forma la vista no tiene conocimiento de
lo que sucede con el modelo, se aísla y se limita a tomar la entrada y presentar los resultados
95
mientras que el modelo se encarga de realizar todas las operaciones necesarias sin necesidad de la
existencia de un controlador.
96
REFERENCIAS
(IANA), I. A. (s.f.). Media Types. Obtenido de http://www.iana.org/assignments/media-
types/media-types.xhtml
A., M. S. (2004). The Ultimatum Game, Fairness, and Cooperation among Big Game Hunters.
Foundations of Human Sociality: Economic Experiments and Ethnographic Evidence from
Fifteen Small-Scale Societies, 413-435.
Books, B. (2007). The Naked Brain. Broadway Books.
Brim Orville G., D. C. (1962). Personality and Decision Processes: Studies in the Social Psychology of
Thinking. Stanford.
Chamlers, A. F. (2010). ¿Que es esa cosa llamada ciencia? Siglo XXI.
Deusto. (2004). La toma de decisiones. (G. Planeta, Ed.)
Dewey, J. (1978). How We Think. (M. Works, Ed.)
Drucker, P. F. (s.f.). La decisión eficaz. Harvard Business Review.
Eckstein, R. (Marzo de 2007). Java SE Application Design With MVC. Obtenido de
http://www.oracle.com/technetwork/articles/javase/index-142890.html
Gilbert, D. (2006). Tropezar con la Felicidad. Destino.
Gladwell, M. (2007). Blink Inteligencia Intuitiva. PUNTO DE LECTURA.
Hammond, J. S. (2004). Las trampas ocultas de la adopción de decisiones. Grupo Planeta.
Hansson, S. O. (2005). Decision Theory: A Brief Introduction. Decision Theory: A Brief Introduction.
Harford, T. (2008). La Lógica Oculta de la Vida. TEMAS DE HOY.
Hayashi, A. (2004). Cuándo confiar en el instinto. Harvard Business Review.
js, k. (s.f.). Knockout js. Obtenido de http://knockoutjs.com/
97
Kahneman, D. (2011). Thinking Fast and Slow. Farrar, Straus and Giroux.
Keen, P. G. (1978). Decision Support Systems: An Organizational Perspective. Addison-Wesley.
Lehrer, J. (2010). How We Decide. Mariner Books.
Maboussin, M. J. (2012). Think Twice. Harvard Business Review Press.
Mintzberg, H. D. (1976). The Structure of ‘Unstructured’ Decision Processes. Administrative
Sciences Quarterly.
Riddley, M. (2011). El optimista racional. Taurus Pensamiento.
Roth, G. (Abril de 2010). HTML5 Server-Push Technologies. Obtenido de
https://today.java.net/article/2010/04/26/html5-server-push-technologies-part-2
Russell L, A. (1987). The Art of Problem Solving. John Wiley & Sons.
Shiba, S. A. (1993). A New American TQM: Four Practical Revolutions in Management. Productivity
Press.
Simon, H. A. (1960). The New Science of Management Decision. Prentice-Hall.
Spring Framework. (s.f.). Obtenido de http://projects.spring.io/spring-framework/
Sutton, R. I. (Septiembre de 1995). What theory is not. Administrative Science, 40, 371-384.
Thymeleaf. (s.f.). Obtenido de http://www.thymeleaf.org/
Von Neumann, J., & Morgenstern, O. (1953). Theory of Games and Economic Behavior. Princeton,
NJ.
W3C. (s.f.). HTTP - Hypertext Transfer Protocol. Obtenido de http://www.w3.org/Protocols/
Witte, E. (1972). Field research on complex decision-making processes –the phase theorem.
International Studies of Management and Organization.
98
99
