Informe Final Proyecto de Título MARZO 2013 Rev CCFX

PONTIFICIA UNIVERSIDAD CATLICA DE VALPARASO
FACULTAD DE INGENIERA
ESCUELA DE INGENIERA INFORMTICA
MARZO 2013
Visualizador Tridimensional para un
Sistema Multiagente aplicado al Problema
de Transporte de Pasajeros
GERARDO ISMAEL URBINA AMPUERO
INFORME FINAL DE PROYECTO
PARA OPTAR AL TTULO PROFESIONAL DE
INGENIERO DE EJECUCIN EN INFORMTICA
PONTIFICIA UNIVERSIDAD CATLICA DE VALPARASO
FACULTAD DE INGENIERA
ESCUELA DE INGENIERA INFORMTICA
MARZO 2013

Visualizador Tridimensional para un
Sistema Multiagente aplicado al Problema
de Transporte de Pasajeros
GERARDO ISMAEL URBINA AMPUERO
Profesor Gua: Claudio Cubillos Figueroa
Profesor Co-Referente: Ricardo Soto De Giorgis
Carrera: Ingeniera de Ejecucin en Informtica

Dedicado a mis padres, familiares y amigos,
por su apoyo incondicional a lo largo de todo
este proceso, permitindome de este modo el
poder llevar a cabo cada una de mis metas.

i
ndice
Lista de Figuras .........................................................................................................................v
Lista de Tablas.........................................................................................................................vii
Resumen ................................................................................................................................. viii
Captulo 1: Descripcin del Tema............................................................................................1
1.1 Introduccin ........................................................................................................................... 1
1.2 Definicin de Objetivos.......................................................................................................... 2
1.2.1 Objetivo General ....................................................................................................................... 2
1.2.2 Objetivos Especficos................................................................................................................ 2
1.3 Planificacin del Proyecto ..................................................................................................... 2
1.4 Metodologa de Trabajo ........................................................................................................ 5
1.4.1 Fases de gil UP....................................................................................................................... 5
1.4.2 Disciplinas e Iteraciones de gil UP ........................................................................................ 6
1.5 Estructura del Documento .................................................................................................... 7
Captulo 2: Agentes Inteligentes y Sistemas Multiagente ......................................................9
2.1 Agentes.................................................................................................................................... 9
2.1.1 Concepto de Agente.................................................................................................................. 9
2.1.2 Entorno de un Agente ............................................................................................................. 10
2.2 Agentes Inteligentes ............................................................................................................. 11
2.3 Tipologa de Agentes............................................................................................................ 12
2.4 Sistemas Multiagente........................................................................................................... 13
2.5 Arquitecturas para la Construccin de Agentes ............................................................... 14
2.5.1 Deliberativas ........................................................................................................................... 15
2.5.2 Reactivas ................................................................................................................................. 16
2.5.3 Hbridas................................................................................................................................... 17
2.6 Infraestructura de Agentes ................................................................................................. 19
2.6.1 Ontologas............................................................................................................................... 19
2.6.2 Lenguajes de Comunicacin para Agentes (ACL).................................................................. 19
2.6.2.1 KQML ......................................................................................................................................20
2.6.2.2 FIPA ACL.................................................................................................................................21
2.6.3 Protocolos de Interaccin para Agentes (AIP) ........................................................................ 21
2.6.3.1 FIPA IPs ...................................................................................................................................22
2.7 Metodologas de Desarrollo de Agentes ............................................................................. 23
Eliminado: 4
Eliminado: 4
Eliminado: 5
Eliminado: 8
Eliminado: 8
Eliminado: 8
Eliminado: 9
Eliminado: 9
Eliminado: 11
Eliminado: 12
Eliminado: 13
Eliminado: 13
Eliminado: 14
Eliminado: 15
Eliminado: 17
Eliminado: 17
Eliminado: 17
Eliminado: 18
Eliminado: 18
Eliminado: 19
Eliminado: 19
Eliminado: 20

ii
2.7.1 MaSE................................................................................................................................... 23
2.7.2 GAIA................................................................................................................................... 24
2.7.3 PASSI .................................................................................................................................. 25
2.8 Plataformas de Desarrollo de Agentes................................................................................ 28
2.8.1 JADE................................................................................................................................... 28
Captulo 3: Motores Grficos 3D...........................................................................................30
3.1 Qu es un Motor Grfico?................................................................................................. 30
3.2 APIs Grficas ....................................................................................................................... 30
3.2.1 OpenGL .................................................................................................................................. 31
3.2.2 Direct3D.................................................................................................................................. 31
3.3 Representacin Tridimensional de Geometras ................................................................ 32
3.4 Tcnicas Utilizadas por Motores Grficos 3D................................................................... 34
3.4.1 Renderizado ............................................................................................................................ 34
3.4.2 VSync...................................................................................................................................... 34
3.4.3 rboles BSP............................................................................................................................ 35
3.4.4 Antialiasing............................................................................................................................. 35
3.4.5 Iluminacin y Transformacin (T&L) .................................................................................... 36
3.4.6 Sombreado .............................................................................................................................. 38
3.4.7 Niveles de Detalle (LODs)...................................................................................................... 38
3.4.8 Vertex, Geometry y Pixel Shaders .......................................................................................... 39
3.4.9 Radiosity ................................................................................................................................. 39
3.5 Listado de Motores Grficos 3D......................................................................................... 40
Captulo 4: Modelado 3D........................................................................................................42
4.1 Tcnicas de Modelado.......................................................................................................... 42
4.1.1 Modelado Poligonal ................................................................................................................ 43
4.1.2 Modelado mediante Splines .................................................................................................... 43
4.1.3 Digital Sculpting ..................................................................................................................... 44
4.2 Texturizado........................................................................................................................... 45
4.2.1 Tcnicas de Texturizado ......................................................................................................... 46
4.2.1.1 Procedurales..............................................................................................................................46
4.2.1.2 Vertex Paint ..............................................................................................................................47
4.2.1.3 Texturizado por Imagen............................................................................................................47
4.3 Listado Softwares de Modelado 3D.................................................................................... 48
Captulo 5: Seleccin de Sistema Multiagente ......................................................................51
5.1 Sistemas de Transporte Inteligente .................................................................................... 51
Eliminado: 20
Eliminado: 22
Eliminado: 23
Eliminado: 25
Eliminado: 25
Eliminado: 26
Eliminado: 26
Eliminado: 26
Eliminado: 27
Eliminado: 27
Eliminado: 28
Eliminado: 31
Eliminado: 31
Eliminado: 31
Eliminado: 32
Eliminado: 32
Eliminado: 33
Eliminado: 34
Eliminado: 36
Eliminado: 36
Eliminado: 38
Eliminado: 38
Eliminado: 41
Eliminado: 41
Eliminado: 41
Eliminado: 42
Eliminado: 43
Eliminado: 44
Eliminado: 44
Eliminado: 44
Eliminado: 45
Eliminado: 46
Eliminado: 47
Eliminado: 50
Eliminado: 50

iii
5.2 Sistemas Flexibles de Transporte de Pasajeros................................................................. 52
5.3 Dial-a-Ride Problem............................................................................................................ 53
5.4 Arquitectura MADARP ...................................................................................................... 54
5.5 SIM-MADARP Baranlloni.................................................................................................. 57
Captulo 6: Desarrollo del Proyecto.......................................................................................60
6.1 Presentacin del Caso de Estudio....................................................................................... 60
6.1.1 Problemas Relacionados ......................................................................................................... 60
6.1.2 Tecnologas Utilizadas............................................................................................................ 61
6.1.3 Desarrollo del Caso de Estudio............................................................................................... 61
6.2 Diseo del Sistema................................................................................................................ 62
6.2.1 Anlisis del Sistema Existente ................................................................................................ 62
6.2.2 Modelo Requerimientos del Sistema ...................................................................................... 64
6.2.2.1 Identificacin de Agentes .........................................................................................................64
6.2.2.2 Identificacin de Roles .............................................................................................................66
6.2.2.3 Especificacin de Tareas...........................................................................................................69
6.2.3 Modelo de Sociedad de Agentes ............................................................................................. 70
6.2.3.1 Descripcin de Ontologa de Comunicacin.............................................................................71
6.2.3.2 Descripcin de Roles ................................................................................................................72
6.2.4 Modelo de Implementacin de Agentes.................................................................................. 73
6.2.4.1 Definicin de la Estructura Multiagente ...................................................................................73
6.2.4.2 Definicin de la Estructura de los Agentes Individuales...........................................................75
6.2.4.3 Datos de Entrada.......................................................................................................................78
6.2.5 Diseo Motor Grfico............................................................................................................. 79
6.2.5.1 Diagrama Casos de Uso............................................................................................................80
6.2.5.2 Diagrama de Actividad .............................................................................................................81
6.2.5.3 Diagrama de Clases ..................................................................................................................84
6.2.6 Diseo de la Ciudad................................................................................................................ 85
Captulo 7: Pruebas de Software............................................................................................87
7.1 Planificacin de las Pruebas................................................................................................ 88
7.2 Diseo de las Pruebas .......................................................................................................... 88
7.3 Datos de Prueba ................................................................................................................... 92
Captulo 8: Implementacin ...................................................................................................98
8.1 Conexin entre el SMA y el Motor Grfico....................................................................... 98
8.2 Desarrollo e Integracin de Modelos 3D............................................................................ 99
8.3 Interfaz Grfica de Usuario del Simulador ..................................................................... 103
Eliminado: 51
Eliminado: 52
Eliminado: 53
Eliminado: 56
Eliminado: 59
Eliminado: 59
Eliminado: 59
Eliminado: 60
Eliminado: 60
Eliminado: 74
Eliminado: 74
Eliminado: 76
Eliminado: 79
Eliminado: 80
Eliminado: 82
Eliminado: 88
Eliminado: 89
Eliminado: 97
Eliminado: 97
Eliminado: 98
Eliminado: 101

iv
8.4 Rutas y Asignacin de Caminos........................................................................................ 105
8.5 Interfaz Grfica de Usuario de la Interfaz 3D................................................................. 108
8.6 Modificaciones Anexas ...................................................................................................... 110
Captulo 9: Conclusiones ......................................................................................................112
9.1 Sobre los Diferentes Tpicos y su Integracin................................................................. 112
9.2 Sobre los Objetivos Cumplidos......................................................................................... 112
9.3 Sobre el Trabajo Futuro.................................................................................................... 114
Referencias .............................................................................................................................115
Anexos.......
A: Ontologa del dominio proyecto relacionado..
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101

v

Lista de Figuras
Figura 1.1 Ciclo de vida de Agile UP [URL 1, 2005] .................................................................5
Figura 1.2 Versiones incrementales en el tiempo [URL 1, 2005] ...............................................7
Figura 2.1 Interaccin agente/entorno [Salazar, 2003]..............................................................10
Figura 2.2 Arquitectura BDI [Mas, 2005] .................................................................................16
Figura 2.3 Ejemplo de arquitectura reactiva [Mas, 2005] .........................................................16
Figura 2.4 Arquitectura de subsuncin [Brooks, 1985].............................................................17
Figura 2.5 Arquitecturas de agente por capas [Mller et al., 1995] ..........................................18
Figura 2.6 Etapas de desarrollo en MaSE [Wood y DeLoach, 2001] .......................................24
Figura 2.7 Modelo GAIA [Garro, 2012] ...................................................................................25
Figura 2.8 Modelos de la metodologa PASSI [Burrafato y Cossentino, 2002] .......................26
Figura 3.1 Elementos bsicos de una geometra [Elab. Propia] ................................................32
Figura 3.2 Ejemplo polgonos con tringulos [Ezequiel, 2004] ................................................33
Figura 3.3 Primitivas geomtricas bsicas [Elab. Propia] .........................................................34
Figura 3.4 Ejemplo de error en sincronizacin de frames [URL 3, 2012] ................................35
Figura 3.5 Ejemplo rbol BSP [URL 4, 2011] ..........................................................................35
Figura 3.6 Ejemplo imagen con y sin antialiasing [Ezequiel, 2004].........................................36
Figura 3.7 Proceso de transformacin de coordenadas 3D a 2D [URL 5, 2000] ......................37
Figura 3.8 Ejemplo tipos de luces [Ezequiel, 2004]..................................................................37
Figura 3.9 Ejemplo de shadow map [Ahokas, 2002] ................................................................38
Figura 3.10 Ejemplo de diferentes tipos de LODs [URL 6, 2009]............................................39
Figura 3.11 Ejemplo de radiosidad [URL 7, 2012] ...................................................................40
Figura 4.1 Ejemplo box modeling [URL 15, 2006] ..................................................................43
Figura 4.2 Ejemplo NURBS modeling [URL 16, 2004] ...........................................................44
Figura 4.3 Utilizacin de un perfil [URL 17, 2011]..................................................................44
Figura 4.4 Ejemplo de sculpting [URL 18, 2011] .....................................................................45
Figura 4.5 Ejemplo mapeado de textura [URL 19, 2008] .........................................................46
Figura 4.6 Ejemplo texturas procedurales [URL 20, 2009] ......................................................46
Figura 4.7 Ejemplo de vertex paint [URL 22 2009]..................................................................47
Figura 4.8 Texturizado mediante UV Map [URL 23, 2006] .....................................................48
Figura 5.1 Arquitectura MADARP [Cubillos, 2005] ................................................................55
Figura 5.2 Identificacin de agentes proyecto relacionado [Baranlloni, 2009].........................57
Figura 5.3 Imagen del estado final de la interfaz proyecto relacionado [Baranlloni, 2009] .....59
Figura 5.4 Modelos 3D proyecto relacionado [Baranlloni, 2009]............................................59
Figura 6.1 Descripcin del dominio proyecto relacionado [Donoso y Sandoval, 2009]...........63
Figura 6.2 Diagrama de identificacin de agentes [Elab. Propia] .............................................65
Eliminado: 4
Eliminado: 6
Eliminado: 8
Eliminado: 14
Eliminado: 14
Eliminado: 15
Eliminado: 16
Eliminado: 21
Eliminado: 22
Eliminado: 23
Eliminado: 28
Eliminado: 30
Eliminado: 31
Eliminado: 32
Eliminado: 32
Eliminado: 33
Eliminado: 34
Eliminado: 34
Eliminado: 35
Eliminado: 36
Eliminado: 38
Eliminado: 41
Eliminado: 42
Eliminado: 43
Eliminado: 43
Eliminado: 44
Eliminado: 45
Eliminado: 46
Eliminado: 47
Eliminado: 54
Eliminado: 56
Eliminado: 58
Eliminado: 58

vi
Figura 6.3 Escenario de captura de informacin inicial [Elab. Propia].....................................67
Figura 6.4 Escenario de generacin de evento en vehculo [Elab. Propia] ...............................68
Figura 6.5 Escenario de generacin de evento en cliente [Elab. Propia] ..................................69
Figura 6.6 Especificacin de tareas [Elab. Propia]....................................................................70
Figura 6.7 Descripcin de ontologa de comunicacin [Elab. Propia]......................................71
Figura 6.8 Descripcin de roles [Elab. Propia] .........................................................................72
Figura 6.9 Definicin de la estructura Sistema Multiagente [Elab. Propia]..............................74
Figura 6.10 Definicin de la estructura agente Manager3D [Elab. Propia] ..............................76
Figura 6.11 Definicin de la estructura agente TripGen [Elab. Propia]....................................77
Figura 6.12 Definicin de la estructura agente SchedGen [Elab. Propia].................................77
Figura 6.13 Definicin de la estructura agente EventVehicle [Elab. Propia]............................78
Figura 6.14 Definicin de la estructura agente EventClient [Elab. Propia] ..............................78
Figura 6.15 Caso de uso usuario de interfaz [Elab. Propia] ......................................................81
Figura 6.16 Diagrama de actividad [Elab. Propia] ....................................................................82
Figura 6.17 Diagrama de clases interfaz [Elab. Propia] ............................................................85
Figura 6.18 Grafo no dirigido de paraderos [Elab. Propia] .......................................................86
Figura 6.19 Diagrama ciudad a simular [Elab. Propia] .............................................................87
Figura 8.1 Conexin entre SMA y el motor grfico [Elab. Propia] ..........................................98
Figura 8.2 Diseo modelo ciudad 3D [Elab. Propia] ..............................................................100
Figura 8.3 Diseo modelo paradero 3D [Elab. Propia] ...........................................................101
Figura 8.4 Diseo modelo vehculo 3D [Elab. Propia] ...........................................................101
Figura 8.5 Diseo modelo cliente 3D en conjunto con su textura UV [Elab. Propia] ............102
Figura 8.6 Panel de actualizacin de eventos de la interfaz 3D [Elab. Propia].......................103
Figura 8.7 Propiedades del archivo de entrada modificable mediante panel [Elab. Propia]...104
Figura 8.8 Rutas mediante splines [Elab. Propia] ...................................................................105
Figura 8.9 Implementacin del pathfinding [Elab. Propia] .....................................................106
Figura 8.10 Men desplegable de la GUI 3D clientes y vehculos [Elab. Propia] ..................108
Figura 8.11 Men desplegable de la GUI 3D nodos de parada [Elab. Propia] .......................109
Figura 8.12 Caja de texto con informacin de los clientes de la GUI 3D [Elab. Propia]........109
Figura 8.13 Edificios sin textura y con baja opacidad [Elab. Propia] .....................................110
Figura A.1 Ontologa del dominio proyecto relacionado [Donoso y Sandoval, 2009] ...........120
Eliminado: 73
Eliminado: 75
Eliminado: 77
Eliminado: 78
Eliminado: 79
Eliminado: 97
Eliminado: 99
Eliminado: 100
Eliminado: 100
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101
Eliminado: 101

vii

Lista de Tablas
Tabla 1.1 Carga Gantt del proyecto total [Elab. Propia] .............................................................3
Tabla 6.1 Archivo de inicializacin de datos [Donoso y Sandoval, 2009] ...............................79
Tabla 7.1 Prueba activacin/desactivacin VSync [Elab. Propia] ............................................89
Tabla 7.2 Prueba cambios en resolucin de la pantalla [Elab. Propia] .....................................89
Tabla 7.3 Prueba aumento/disminucin calidad antialiasing [Elab. Propia].............................89
Tabla 7.4 Prueba iniciacin y carga de modelos 3D [Elab. Propia]..........................................90
Tabla 7.5 Prueba creacin de luces y sombras [Elab. Propia]...................................................90
Tabla 7.6 Prueba creacin de la msica ambiental [Elab. Propia] ............................................90
Tabla 7.7 Prueba aplicacin del Path Finding [Elab. Propia]....................................................91
Tabla 7.8 Prueba creacin del skybox [Elab. Propia]................................................................91
Tabla 7.9 Prueba modificacin de la cmara [Elab. Propia] .....................................................92
Tabla 7.10 Prueba captura de evento [Elab. Propia] .................................................................92
Tabla 7.11 Prueba generacin de evento [Elab. Propia]............................................................92
Tabla 7.12 Matriz de distancias [Elab. Propia] .........................................................................93
Tabla 7.13 Archivo de datos grafo [Elab. Propia].....................................................................94
Tabla 7.14 Archivo de datos buses [Elab. Propia] ....................................................................95
Tabla 7.15 Archivo de datos clientes [Elab. Propia] .................................................................96
Eliminado: 80

viii

Resumen
La visualizacin 3D es una herramienta muy til al momento de querer representar
sistemas complejos, en los cuales no se puede ver de forma directa su completo
funcionamiento. En el caso de los Sistemas Multiagente, la utilizacin de una interfaz 3D
permite comprender con mayor facilidad las diversas comunicaciones e interacciones que
realizan los agentes entre si, otorgndole a cada uno de ellos una representacin propia en el
mundo virtual. El objetivo de este proyecto, adems de crear dicha interfaz, es otorgar un
medio de interaccin externo con el sistema, en el cual se puedan inducir conductas que
influyan directamente en su funcionamiento interno. Para el desarrollo de la interfaz 3D, se ha
seleccionado el problema de transporte de pasajeros, especificamente el Dynamic Dial-a-Ride
Problem (D-DARP).
Palabras Claves: Visualizacin 3D, Sistemas Multiagente, Dynamic Dial-a-Ride Problem.
Abstract
The 3D visualization is a very useful tool when wanting to represent complex systems,
in which cannot be seen in direct form its complete operation. In the case of Multi Agent
Systems, using a 3D interface allows to understand more easily the various communications
and interactions made by agents with each other, giving each one its own representation in the
virtual world. The objective of this project, besides creating the above mentioned interface, is
to provide a means of external interaction with the system, which can induce behaviors that
directly influence their internal functioning. For the development of the 3D interface, the
passenger transportation problem was selected, specifically the Dynamic Dial-a-Ride Problem
(D-DARP).
Key Words: 3D Visualization, Multiagent Systems, Dynamic Dial-a-Ride Problem.
Eliminado: sistemas
Eliminado:
Eliminado:
Eliminado: the
Eliminado: we
Eliminado: the problem of
passenger transportation problem

ix

1
Captulo 1: Descripcin del Tema
1.1 Introduccin
La utilizacin de agentes en la resolucin de problemas ltimamente ha tomado una gran
relevancia. Esto se debe principalmente a su capacidad de resolver complejos problemas, en
especial cuando estos poseen una naturaleza inherentemente distribuida. Cuando un problema
es solucionado mediante diversos agentes, los cuales interactan unos con otros, e
intercambian mensajes, se est refiriendo a un Sistema Multiagente (MAS).
Debido a la gran cantidad de elementos que conforman la tecnologa de agentes, en
muchas ocasiones se hace uso de interfaces de monitoreo, las cuales consisten en una serie de
paneles que entregan informacin general sobre el funcionamiento del sistema. En el
desarrollo de aplicaciones con una magnitud considerable, esta informacin no es suficiente
para comprender exactamente cada una de las comunicaciones realizadas por los diversos
agentes, siendo necesaria la utilizacin de interfaces con un mayor grado de complejidad.
Es por esto, que en el siguiente proyecto se propone la realizacin de una interfaz 3D, la
cual permitir representar de forma grfica los componentes ms importantes del sistema
seleccionado, adems de las interacciones y el intercambio de mensajes que realizan los
agentes. A su vez, tambin se propone un medio de interaccin externo con el sistema, es
decir, el permitir realizar ciertas acciones en la interfaz, las cuales tengan como consecuencia
un determinado comportamiento interno en el simulador, permitiendo de esta forma
monitorizar, analizar y comprobar su correcto funcionamiento. En este proyecto, aparte de
considerar el aspecto funcional de la interfaz, tambin se ha considerado el aspecto esttico de
la misma, es decir, realizar un mundo que posea elementos caractersticos del sistema en el
cual se est trabajando.
Debido a que la implementacin de la interfaz 3D se debe realizar sobre un MAS en
particular, se ha seleccionado un sistema de transporte de respuesta a demanda (DRT), en el
cual interactan principalmente dos actores: vehculos y clientes. En este sistema, se busca
solucionar los tpicos problemas producidos en el transporte urbano e interurbano mediante la
utilizacin de diversos dispositivos tecnolgicos, considerando adems un recorrido adaptable
a las diversas demandas de transporte y tipos de servicios solicitados por los diferentes
clientes.
Eliminado: , e

2

1.2 Definicin de Objetivos
1.2.1 Objetivo General
Desarrollar una interfaz tridimensional que represente grficamente un Sistema
Multiagente aplicado al problema de transporte de pasajeros, utilizando el motor
jMonkeyEngine para la visualizacin del mundo 3D y JADE como plataforma para el
desarrollo de agentes.
1.2.2 Objetivos Especficos
Comprender el funcionamiento de los Sistemas Multiagente en conjunto con el sistema
de transporte de pasajeros seleccionado.
Comprender el uso de herramientas para la creacin de modelos 3D y la forma de
incorporar dichos modelos al motor grfico seleccionado.
Realizar el diseo del sistema.
Implementar la interfaz tridimensional del Sistema Multiagente.
Realizar pruebas del sistema.
1.3 Planificacin del Proyecto
La planificacin del proyecto pretende estructurar las diferentes actividades e hitos que
forman parte del proyecto. Una buena planificacin puede significar el xito y cumplimiento
de cada uno de los objetivos propuestos, con los costos y tiempos establecidos. A partir de los
objetivos planteados en el apartado 1.2.1 y 1.2.2, la planificacin del proyecto fue dividida en
cuatro etapas, las cuales son:
1) Recoleccin de informacin y anlisis investigativo: En esta etapa, se realiza todo el
proceso de investigacin y recoleccin de informacin correspondiente a las diferentes
reas abordadas en este proyecto: Sistemas Multiagente, Motores Grficos, Sistemas
de Transporte de Pasajeros, ente otros.
2) Diseo y desarrollo de prototipos: Una vez finalizado el proceso de recoleccin e
investigacin, se procede a realizar el diseo del sistema en conjunto con el desarrollo
de diversos prototipos incrementales. Esto permite validar tanto el diseo, como el
funcionamiento de las diversas tecnologas aplicadas en la resolucin del problema.
Con formato: Numeracin y
vietas
Eliminado: Investigar
Eliminado: Investigar
Eliminado:

3
3) Integracin e implementacin: Se integran e implementan los diferentes prototipos y
diseos creados en la etapa anterior, permitiendo de esta forma, realizar en la etapa
siguiente las pruebas y validaciones correspondientes.
4) Pruebas y validaciones de aplicacin: Se realizan pruebas exhaustivas sobre la
aplicacin final, con el fin de validar los requerimientos iniciales del sistema.
Tabla 1.1 Carga Gantt del proyecto total [Elab. Propia]

La Tabla 1.1 detalla la forma en que se estructuran y planifican cada una de las
actividades que conforman este proyecto, en donde se indican las fechas de inicio y de trmino
Con formato: Ingls (Estados
Unidos), No revisar la
ortografa ni la gramtica

4
correspondientes a los avances y entregables necesarios para cumplir con los objetivos y metas
propuestas, abarcando de esta forma la totalidad del tiempo dispuesto.

5

1.4 Metodologa de Trabajo
Para el desarrollo de este proyecto se ha decidido utilizar el modelo de proceso de
software Agile UP (AUP). Esta metodologa bsicamente otorga un proceso simple y fcil de
entender para el desarrollo de software mediante diversos conceptos y tcnicas rescatadas de
la Metodologa gil y Rational UP (RUP) [URL 1, 2005]. RUP es considerado como una
herramienta rgida y conducida por la metodologa en cascada, por lo cual se ha flexibilizado
con el fin de poder adaptarse a proyectos cambiantes y de tamaos moderados (respecto a
tiempo y recursos), surgiendo de esta forma AUP [Prabhudas, 2008], [Cans et al., 2003]. En
la Figura 1.1 se puede observar el ciclo de vida de esta metodologa, en la que se han
redefinido tanto las fases de RUP como sus diferentes disciplinas.

Figura 1.1 Ciclo de vida de Agile UP [URL 1, 2005]
1.4.1 Fases de gil UP
El desarrollo del proyecto mediante la metodologa AUP implica descomponerse en
fases seriales, esto quiere decir, que cada fase se realiza una tras otra, manteniendo siempre la
relacin que estas poseen. A continuacin se describen las cuatro fases que lo componen
[Prabhudas, 2008]:
1) Iniciacin: Se establece el alcance inicial del proyecto, se priorizan los requerimientos,
se identifica la visin de la arquitectura, y se consideran otros puntos, como el
financiamiento y la aceptacin por parte del involucrado.

6
2) Elaboracin: Se analizan detalladamente los requerimientos, se mejora e inicia el
modelamiento de la arquitectura inicial y se comienzan a realizar a su vez
implementaciones del software.
3) Construccin: Se construye software funcional, considerando las pruebas y el
desarrollo como actividades en conjunto.
4) Transicin: En esta fase se consideran las validaciones y el despliegue final del
proyecto. Los defectos que no pueden ser solucionados en versiones actuales se
solucionan en versiones futuras.
1.4.2 Disciplinas e Iteraciones de gil UP
Adems de las cuatro fases de AUP, existen una serie de disciplinas desarrolladas de
forma iterativa, las cuales en algunos casos pueden realizarse de forma simultnea, estas
disciplinas son [URL 1, 2005]:
a) Modelado: Se intenta comprender el negocio de la organizacin, el problema del
dominio y se identifican soluciones viables.
b) Implementacin: Se lleva a cdigo ejecutable los modelos creados, para posteriormente
poder realizar pruebas del sistema.
c) Pruebas: Se realiza con el fin de asegurar la calidad del software que se est
desarrollando. En esta disciplina se considera la deteccin de defectos, validaciones del
sistema y verificaciones de requerimientos.
d) Despliegue: Se planifica la entrega del proyecto y la ejecucin del plan con que se
realizar dicha entrega.
e) Administracin de la configuracin: Se verifican versiones del trabajo, el control y la
administracin de cambios.
f) Administracin del proyecto: El objetivo de esta disciplina es dirigir cada una de las
actividades a lo largo de todo el proyecto.
g) Entorno: Asegurar que las herramientas estn disponibles para cuando el equipo del
proyecto las necesite.
Al igual que otras metodologas, en AUP se entregan diversas iteraciones a medida que
se avanza en el proyecto (Figura 1.2), estas se pueden utilizar para realizar un aseguramiento
de calidad, pruebas, procesos de despliegue, entre otros. Constituyendo un resultado de valor
para el negocio.
vietas
vietas

7

Figura 1.2 Versiones incrementales en el tiempo [URL 1, 2005]

1.5 Estructura del Documento
El presente documento se encuentra estructurado a travs de diversos captulos, cada uno
de los cuales entrega informacin relativa a diversas temticas en particular, pero siempre
manteniendo una cohesin respecto al tema en el cual se est trabajado. A continuacin se
presenta un resumen de cada uno de los captulos:
Captulo 1 Descripcin del Tema: Captulo introductorio al tema, el cual considera
aspectos como la metodologa de trabajo a utilizar, la definicin de objetivos y la planificacin
tentativa para cada una de las fases necesarias en el desarrollo del proyecto.
Captulo 2 Agentes Inteligentes y Sistemas Multiagente: Se exponen los diferentes
elementos que conforman la tecnologa de agentes, desde el concepto de agente, hasta las
diversas plataformas para su implementacin.
Captulo 3 Motores Grficos 3D: Se presentan los motores grficos utilizados para la
creacin de entornos 3D en tiempo real, adems de las diversas tcnicas que estos utilizan.
Captulo 4 Modelado 3D: Se explican las diversas tcnicas utilizadas para la creacin de
modelos 3D, los cuales finalmente formarn parte del entorno creado con el motor grfico.
Captulo 5 Seleccin de Sistema Multiagente: Se realiza una breve introduccin a los
Sistemas de Transporte Inteligente y los Sistemas de Transporte Flexibles. Adems se explica
el funcionamiento de la arquitectura MADARP, la cual es la base del sistema de transporte
seleccionado para la creacin del visualizador 3D. Finalmente se presenta el proyecto de
magister realizado en [Baranlloni, 2009].
Captulo 6 Desarrollo del Proyecto: Se presenta el caso de estudio en conjunto con la
solucin al problema. Adems se realiza toda la fase de diseo, tanto del Sistema Multiagente
como del motor grfico.
Eliminado: Salto de pgina

8
Captulo 7 Pruebas de Software: Se verifica que se estn cumpliendo de manera correcta
los objetivos propuestos y tambin se valida todo el proceso que se lleva a cabo en el ciclo de
vida de la aplicacin.
Captulo 8 Implementacin: Se realiza un anlisis en base al proceso de implementacin
llevado a cabo y sus resultados, as como tambin se presentan algunas de las tcnicas
empleadas en la interfaz 3D a fin de mejorar su resultado final.
Captulo 9 Conclusiones: Por ltimo, en este captulo se realiza una comprensin general
de los conceptos y se presentan las diversas conclusiones obtenidas a partir de la creacin de
este proyecto.

9

Captulo 2: Agentes Inteligentes y Sistemas Multiagente
A lo largo de los aos 70, los resultados obtenidos a partir de diversos estudios e
investigaciones cientficas en reas tales como la inteligencia artificial, la informtica
distribuida, la ingeniera de software, las telecomunicaciones, entre otras., han dado origen a
nuevas corrientes tecnolgicas, como los Sistemas Multiagente, los cuales buscan solucionar
problemas complejos mediante la comunicacin y el razonamiento de forma cooperativa y
distribuida. En este captulo se presentar todo lo relacionado con la tecnologa de Sistemas
Multiagente, comenzando desde los conceptos ms bsicos hasta llegar a las plataformas de
desarrollo de agentes.
2.1 Agentes
2.1.1 Concepto de Agente
Actualmente existe una gran cantidad de definiciones para el trmino de agente por parte
de investigadores en este campo, algunas de las cuales se adecuan a la lnea de investigacin
en la que trabajan o el problema el cual estn desarrollando. Segn la RAE [URL 2, 2010],
agente se define como una persona o cosa que produce un efecto, persona que obra con
poder de otra, que obra o tiene virtud de obrar. A pesar que estas definiciones entregan
algunas de las caractersticas propias de un agente de software, no son suficientes como
elementos diferenciadores de otras entidades.
Una de las muchas definiciones para el trmino de agente es: Toda entidad que puede
percibir su entorno por medio de sensores y actuar contra este a travs de efectores [Rusell
y Norvig, 1995]. En esta definicin se pueden observar algunas caractersticas de un agente,
las cuales son la capacidad de percibir y actuar en un entorno determinado (ver Figura 2.1).

10

Figura 2.1 Interaccin agente/entorno [Salazar, 2003]
Otra definicin de agente muy citada por investigadores es la de [Wooldridge, 1996], la
cual dice: Un agente es un sistema informtico situado en un ambiente y que es capaz de
realizar acciones de forma autnoma con el fin de conseguir sus objetivos de diseo. En este
caso se ha incorporado la capacidad de autonoma en el agente y tambin se ha acotado a un
sistema informtico con un objetivo determinado por el diseador.
2.1.2 Entorno de un Agente
Un agente no puede estar totalmente libre de las dependencias externas ni tampoco ser
totalmente dependiente de ellas, esto quiere decir que un agente siempre depende de factores
externos pero hasta un cierto punto. Segn [Odell et al., 2003]: Un entorno provee las
condiciones bajo las cuales una entidad (objeto o agente) existe. Es por esto que el entorno
juega un papel fundamental en el ciclo de vida de un agente, otorgndole la existencia e
influyendo tanto en su estado como en su comportamiento.
El entorno con el cual interacta un agente se puede clasificar segn diversas
propiedades, las cuales son [Wooldridge, 1996]:
a) Accesible v/s inaccesible: Un entorno accesible es aquel en el cual un agente puede
obtener de forma completa, precisa y actualizada informacin del estado del entorno.
b) Determinstico v/s no determinstico: En un entorno determinstico, cualquier accin
tiene un nico efecto y este es garantizado.
c) Esttico v/s dinmico: Un entorno esttico permanece sin cambios, excepto por las
acciones que ejecuta un agente.
d) Discreto v/s continuo: Un entorno discreto es aquel en el cual un agente puede ejecutar
un nmero finito de acciones y percepciones.
vietas

11
Cabe destacar, que a pesar que se han considerado las caractersticas ms importantes de
los agentes de software y los diferentes ambientes en que estos interactan, actualmente no se
ha logrado llegar a una definicin concreta del trmino agente, esto debido a la ambigedad
que se produce al momento de crear un concepto que abarque todos los tipos de agente que
existen, adems de la gran cantidad de reas en la que se puede aplicar esta tecnologa.
2.2 Agentes Inteligentes
Primero que todo, para hablar de agentes inteligentes es necesario conocer que es la
Inteligencia Artificial (IA). La IA desde sus comienzos hasta principios de los aos 50 se
haba centrado principalmente en el estudio de componentes de la inteligencia, tales como el
razonamiento, la resolucin de problemas, el aprendizaje, entre otros. Todo esto con el fin de
crear sistemas computacionales capaces de pensar no numricamente y as poder solucionar
problemas de forma autnoma. A lo largo de los aos 50 y 60 se realizaron diversos
experimentos cientficos sobre la inteligencia, obteniendo como resultado algunas tcnicas
para su representacin computacional. Luego en los aos 70 se crearon los Sistemas Expertos
(SE) los cuales ya tenan algunas caractersticas propias del ser humano. El surgimiento de los
agentes inteligentes comienza a partir de 1995, en donde diversos investigadores de la IA ven
los agentes como otra rea de gran potencial, debido a su amplia aceptacin, la aparicin de
Internet, el comercio electrnico, la sociedad de la informacin, entre otros [Mas, 2005] y
[Rusell y Norvig, 1995].
Un Agente Inteligente podra definirse como: Una entidad de software que, basndose
en su propio conocimiento, realiza un conjunto de operaciones para satisfacer las
necesidades de un usuario o de otro programa, bien por iniciativa propia o porque alguno de
stos se lo requiere [Hpola y Vargas-Quesada, 2005].
Segn esta definicin, un agente tiene la capacidad de adquirir conocimiento para as
poder tomar decisiones ms acertadas. El aprendizaje de un agente se puede adquirir de
diferentes formas, algunas de las cuales pueden ser [Navarra y Martnez, 2006]:
Observando e imitando el comportamiento del usuario.
Recibiendo instrucciones explcitas del usuario.
Observando a otros agentes.
Pidiendo consejo a otros agentes.
Un agente podra determinarse inteligente si este posee adems las siguientes
caractersticas [Salazar, 2003]:

12
a) Racionalidad: Se basa en la adquisicin de conocimientos de su entorno y aplicacin
de diversas reglas para determinar cmo alcanzar sus objetivos sin que se realicen
intervenciones humanas.
b) Coherencia: El conocimiento almacenado en un agente se debe guardar con un alto
grado de coherencia, de esta forma se obtienen comportamientos esperados.
c) Adaptabilidad: La adaptacin de un agente se adquiere a partir del aprendizaje,
aumentando de esta forma sus conocimientos para poder afrontar los problemas desde
diversos puntos de vista.
Otra caracterstica deseable que debe tener un agente inteligente para satisfacer sus
objetivos de diseo es la flexibilidad, la cual se puede dividir especficamente en tres
elementos [Wooldridge, 1996]:
a) Reactividad: Los agentes inteligentes son capaces de percibir su entorno y responder de
manera oportuna a los cambios que ocurren en l.
b) Pro-Actividad: Los agentes inteligentes son capaces de exhibir un comportamiento
dirigido tomando la iniciativa.
c) Habilidad Social: Los agentes inteligentes son capaces de interactuar con otros agentes
(posiblemente humanos).
2.3 Tipologa de Agentes
Existen diversas clasificaciones para los agentes, las cuales dependen principalmente de
la perspectiva en que se observen, como tambin de las caractersticas propias del sistema que
se desea crear. A continuacin se presentarn algunos tipos de agentes [Mas, 2005], [Hpola y
Vargas-Quesada, 2005] y [Salazar, 2003]:
Agentes cooperativos: Capaces de coordinarse y cooperar con cada uno de los agentes
del sistema, gracias a esto pueden conocer el entorno que los rodea, corroborar
informacin, ser autosuficientes, entre otros. Evitando adems limitaciones como la
falta de conocimiento para resolver un problema.
Agentes mviles: Capacidad de moverse fsicamente por los nodos de una red,
independiente de la arquitectura y plataforma del nodo destino, permitiendo por
ejemplo situarse en un nodo remoto y adquirir informacin local o tomar decisiones de
control respecto a los problemas detectados en el nodo destino. Los pasos para realizar
la movilidad de un agente son:
a) Transformarse en una entidad que pueda transmitirse por una red.
vietas
vietas

13
b) Transmitirse por la red.
c) Reconstruirse hasta ser nuevamente una entidad funcional.
d) Activarse para comenzar a ejecutarse.
Agentes de interfaz: Especializados en la interaccin con el usuario, liberndolo de
tareas habituales, repetitivas y por lo general sencillas.
Agentes de resolucin de conflictos: Los agentes de resolucin de conflictos se
encargan de recibir quejas o negociar con los diferentes agentes, con el fin de entender
el problema que se est llevando a cabo y buscar la mejor solucin. Un agente puede
tener diversos conflictos, los cuales pueden clasificarse en internos y externos:
a) Los conflictos internos se dan en los agentes inteligentes, debido a que en
ocasiones deben realizar procesos interpretacin y razonamiento.
b) Los conflictos externos surgen a partir de la interaccin entre los agentes que
componen el sistema.
Agentes de bsqueda: En algunos entornos dinmicos como Internet la informacin se
almacena de forma descentralizada, lo cual hace necesario utilizar herramientas que
ayuden a su bsqueda. Los agentes de bsqueda se encargan de localizar, recuperar y
almacenar la informacin en un resultado el cual posteriormente se le presenta al
usuario.
A pesar de existir una gran cantidad de tipos de agente, el sistema de trabajo de cada uno
de ellos en conjunto con el dominio al que estn destinados, no es suficiente para abarcar reas
demasiado grandes, esto se debe principalmente a las limitaciones que todava existen al
momento de integrar sistemas de agentes y la estructura en que se almacena la informacin
actualmente [Hpola y Vargas-Quesada, 2005].
2.4 Sistemas Multiagente
La mayora de las veces, los agentes deben trabajar en conjunto con otros para logar
solucionar problemas complejos, los cuales en muchas ocasiones superan las capacidades y
conocimientos individuales de cada agente, construyndose de esta forma sociedades de
agentes que trabajan cooperativamente para encontrar una solucin. De lo anterior se puede
llegar a la siguiente definicin: Un Sistema Multiagente consiste en un nmero de agentes,
los cuales interactan unos con otros, tpicamente intercambiando mensajes a travs de una
infraestructura de red computacional [Wooldridge, 1996]. De este modo, el intercambio de
informacin constituye el principal medio para que los agentes se puedan comunicar y
entender entre s.
vietas
vietas

14
En el caso ms general, los Sistemas Multiagente actan en representacin de los
usuarios, los cuales tienen objetivos y motivaciones muy diferentes. Por lo tanto, el xito de la
interaccin de los agentes requiere que cada uno de estos tenga la capacidad de cooperar,
coordinar y negociar con los dems agentes como tambin con los usuarios del sistema
[Wooldridge, 1996].
Un Sistema Multiagente cooperante posee un conjunto de caractersticas, las cuales
generalmente son [Wesson y Hayes-Roth, 1980] y [Rudowsky, 2004]:
Estar formado por un conjunto de agentes, cada uno con sus propias habilidades.
El Sistema Multiagente debe poseer un objetivo en comn.
Cada agente tiene un conocimiento e informacin incompleta respecto a la solucin
general del problema, realizando comportamientos de forma local.
La informacin se encuentra descentralizada.
No se posee un control del sistema global.
Cada agente tiene un cierto grado de especializacin en un rea determinada del
sistema.
De lo anterior se puede identificar la relevancia que tiene la distribucin tanto de agentes
como de las tareas que estos pueden realizar. La distribucin permite fundamentalmente [Mas,
2005]:
Mantener la autonoma de cada agente.
Eliminar la necesidad de almacenar toda la informacin en un nico agente.
Descentralizar la toma de decisiones, generando de esta forma sistemas ms robustos
ante fallos.
Realizar acciones coordinadas para la resolucin de un problema.
Adaptarse ante cambios, debido a la organizacin dinmica de la arquitectura de
agentes.
2.5 Arquitecturas para la Construccin de Agentes
La arquitectura de un agente determina los mecanismos de interconexin de los mdulos
software/hardware que permiten que un agente pueda realizar determinadas conductas. A
diferencia de otras tecnologas, como la orientacin a objetos o los sistemas expertos, en los
agentes uno se puede encontrar con una gran variedad de arquitecturas. Las arquitecturas

15
especifican como se deben descomponer los agentes en un conjunto de mdulos que
interacten entre s para lograr la funcionalidad requerida, el mtodo de descomposicin es
una forma de diferenciar algunos tipos de arquitectura [Salazar, 2003]. A continuacin se
presentan las arquitecturas ms utilizadas, diferenciadas por el modelo de razonamiento que
utilizan.
2.5.1 Deliberativas
Son aquellas arquitecturas que utilizan modelos de representacin simblica del
conocimiento. Estos agentes comienzan de un estado inicial y mediante una serie de planes
alcanzan sus objetivos. El sistema de planificacin que debe poseer el agente se encarga de
determinar los pasos que deben llevarse a cabo para lograr cumplir sus objetivos. Para la
implementacin de una arquitectura deliberativa, se debe encontrar una descripcin simblica
del problema e integrarla al agente, de esta forma tendr la capacidad de razonar y realizar las
tareas para las cuales se ha encomendado [Mas, 2005].
Una de las arquitecturas deliberativas ms estudiadas y extendidas actualmente, es la
denominada arquitectura BDI (Belief, Desire, Intention), la cual puede observarse ms
claramente en la Figura 2.2. Esta se basa en la construccin de agentes racionales dotados de
tres actitudes mentales: Creencias, Deseos e Intenciones. Las cuales pueden clasificarse en
[Salazar, 2003]:
a) Actitudes de informacin: Estn relacionadas con el conocimiento que un agente tiene
sobre su entorno (creencias, conocimiento).
b) Pro-actitudes: aquellas que guan el comportamiento del agente (deseo, intencin,
obligacin, eleccin, entre otros).
Desde un punto de vista informtico, las creencias son la forma de representar el estado
del entorno, almacenando eventos pasados y evitando de esta forma el tener que recalcular
informacin previa. Adems en entornos dinmicos es necesario el tener informacin pasada
para poder adaptarse y evolucionar.
Los deseos u objetivos pueden ser simplemente un valor de una variable, como tambin
una expresin simblica de algo. Un objetivo representa algn estado final deseado, por lo que
en conjunto con las creencias podran por ejemplo recuperarse ante un fallo y tener un
recuerdo de por qu ha comenzado su ejecucin y cul es su objetivo.
vietas

16

Figura 2.2 Arquitectura BDI [Mas, 2005]
El sistema necesita comprometerse con los planes y sub-objetivos, pero tambin ser
capaz de reconsiderarlos en los momentos clave. Para esto es necesario tener un conjunto de
caminos de ejecucin o planes vinculados a la consecucin de un objetivo, los cuales adems
pueden ser interrumpidos de una forma apropiada al recibir informacin de cambios en el
entorno, constituyendo de esta forma las intenciones en el agente.
2.5.2 Reactivas
Esta arquitectura se caracteriza por no tener como elemento central de razonamiento un
modelo simblico y por no utilizar razonamiento complejo, teniendo que utilizar nicamente
la informacin actual para decidir su siguiente accin. En las arquitecturas reactivas se pueden
aplicar diversos algoritmos, como por ejemplo el algoritmo de fusin, el cual permite analizar
las salidas para luego determinar qu hacer con ella [Goodridge et al., 1994].

Figura 2.3 Ejemplo de arquitectura reactiva [Mas, 2005]

17
En la Figura 2.3 se puede observar un ejemplo de algoritmo de fusin, en el cual un
agente tiene dos acciones posibles: evitar obstculos y seguir un objeto. Si el entorno requiere
nicamente la accin de evitar obstculos, se debe poder bloquear la otra automticamente
[Mas, 2005].
Un ejemplo de arquitectura reactiva es la propuesta por Roodney Brooks, conocida
como arquitectura de subsuncin [Brooks, 1991]. Esta arquitectura se basa en que la
inteligencia es una propiedad emergente de sistemas complejos, pero que a partir de estos se
puede generar comportamientos inteligentes sin necesidad de construir un modelo simblico.
En esta arquitectura se manejan jerarquas de tareas que definen un comportamiento (ver
Figura 2.4). Suelen estar organizadas en jerarquas de capas, de menor a mayor nivel de
abstraccin [Brooks, 1991].

Figura 2.4 Arquitectura de subsuncin [Brooks, 1985]
2.5.3 Hbridas
Debido a las limitaciones propias de las arquitecturas anteriores, se han planteado
soluciones mediante arquitecturas hbridas, las cuales pretenden combinar aspectos de ambos
modelos. Para esto se puede considerar como primera opcin el construir un agente el cual
este compuesto de dos subsistemas: uno deliberativo, el cual utilice un modelo simblico y
que tenga la capacidad de generar planes, y otro reactivo, el cual reaccione ante los eventos
que se produzcan en su entorno sin tener que poseer un mecanismo de razonamiento complejo
para su funcionamiento [Mas, 2005].
Eliminado: , s

18
La naturaleza de estas arquitecturas son propicias para una estructuracin por capas, la
cual puede ser [Wooldridge, 1996]:
a) Capas horizontales: En las arquitecturas de capas horizontales (ver Figura 2.5(a)),
todas las capas tienen acceso a los sensores y a los actuadores. Lo cual permite por
ejemplo, que si un agente necesita realizar n tipos de tareas, entonces se implementen n
capas diferentes.
b) Capas verticales: En las arquitecturas de capas verticales (ver partes (b) y (c) de la
Figura 2.5), el sensor de entrada y la accin de salida puede ser tratado solo por una de
las capas.

Figura 2.5 Arquitecturas de agente por capas [Mller et al., 1995]
Al igual que en las arquitecturas de subsuncin, las capas se organizan de forma
jerrquica y con informacin del entorno a diferentes niveles de abstraccin. La mayora de las
arquitecturas encuentran suficientes tres niveles [Mas, 2005]:
1) Reactivo, o de ms bajo nivel: Las decisiones se toman a partir de los estmulos del
entorno. Suelen estar implementados mediante arquitecturas de subsuncin.
2) Conocimiento, o nivel intermedio: Centrado en el conocimiento que posee el agente
sobre el medio, usualmente mediante una representacin simblica del conocimiento.
vietas
vietas

19
3) Social: Se manejan aspectos sociales del entorno, como la comunicacin entre agentes
o los deseos e intenciones.
El comportamiento del agente se define mediante la interaccin entre estos tres niveles,
los cuales no necesariamente deben ser iguales para todas las arquitecturas.
2.6 Infraestructura de Agentes
Para hacer posible la interaccin entre los diversos agentes del sistema se necesita una
infraestructura de agentes. Esta proporciona las regulaciones necesarias para que los agentes
puedan comunicarse y entenderse, permitiendo de esta forma compartir el conocimiento. Los
tres elementos que componen esta infraestructura son: ontologas, lenguajes de comunicacin
y protocolos de interaccin.
2.6.1 Ontologas
Las ontologas se utilizan para especificar formalmente la informacin, entregando un
significado comn el cual permite que los agentes puedan entenderse. Ms especficamente
una ontologa podra definirse como: Un conjunto de aserciones que explican los conceptos
involucrados en un dominio [Castillo et al., 2010].
Una ontologa se compone principalmente de seis elementos que permiten formalizar el
conocimiento [Castillo et al., 2010]:
1) Clases: Ideas bsicas las cuales se intentan formalizar.
2) Atributos: Estructura interna de las clases.
3) Relaciones: Interaccin y enlace entre las clases.
4) Funciones: Tipo concreto de relacin la cual identifica un elemento a partir del clculo
de una funcin considerando otros elementos de la ontologa.
5) Instancias: Representacin de objetos determinados de una clase los cuales no pueden
ser divididos, ya que perderan su estructura y funcionalidades.
6) Axiomas: Teoremas declarados sobre las relaciones, que deben cumplir los diferentes
elementos de la ontologa.
2.6.2 Lenguajes de Comunicacin para Agentes (ACL)
La capacidad de comunicar informacin es una de las cualidades ms importantes que
posee un agente, esta permite el intercambio y comprensin de mensajes, como tambin las
vietas

20
formas de comunicacin (protocolos) entre agentes. Para llevar a cabo la comunicacin es
necesario que los agentes comprendan los siguientes tres aspectos:
1) Sintaxis: Estructura de los smbolos utilizados para comunicarse.
2) Semntica: Significado de los smbolos.
3) Pragmtica: Interpretacin de los smbolos.
La mayora de las propuestas para la creacin de un lenguaje de comunicacin entre
agentes se basan en la comunicacin humana, particularmente en la teora del acto del habla,
la cual involucra tres aspectos [Austin, 1962]:
1) Locucin: Emisin fsica desde el punto de vista del emisor.
2) Ilocucin: Significado de lo que dice el emisor.
3) Perlocucin: Acto que resulta de la locucin.
Debido a las ambigedades producidas en la ilocucin de un mensaje, se utilizan
diversos verbos performativos correspondientes a diferentes actos del habla, los cuales buscan
darle una intencin concreta al mensaje.
Existen varios estndares para la creacin de lenguajes de comunicacin entre agentes.
A continuacin se vern los dos ms utilizados: KQML y FIPA ACL.
2.6.2.1 KQML
KQML (Knowledge Query and Manupulation Language) es un lenguaje y protocolo
para el intercambio de informacin y conocimiento entre agentes. El lenguaje KQML puede
dividirse en tres capas: la capa de contenido, la capa de comunicacin y la capa de mensaje.
La capa de contenido posee el contenido real del mensaje a transmitir. La capa de
comunicacin describe los parmetros de bajo nivel de comunicacin, como la identidad del
emisor y receptor, adems de un identificar nico asociado a la comunicacin. Finalmente la
capa de mensaje determina los tipos de interacciones que uno puede tener con un agente que
tambin habla KQML, como tambin el lenguaje y la ontologa a utilizar [Finin et al., 1995].
A partir de estas capas se pueden identificar los elementos que componen el lenguaje KQML:
1) Performative: Especifica la intencin del mensaje.
2) Sender: Identificador del agente que enva el mensaje.
3) Content: Especifica el contenido del mensaje.
4) Receiver: Identificador del agente receptor del mensaje.
vietas
vietas
vietas

21
5) Language: Lenguaje utilizado en el contenido del mensaje.
6) Ontology: Especifica la ontologa utilizada.
7) Reply-with: Identificador que debe ser utilizado en respuesta a este mensaje.
8) In-reply-to: Identificador del mensaje que provoc el envo de este mensaje.
2.6.2.2 FIPA ACL
FIPA ACL es un lenguaje de comunicacin entre agentes propuesto por el estndar
FIPA (Foundation for Intelligent Phisycal Agents). Este posee los mismos elementos que
componen KQML, con la diferencia que este posee un grupo de performatives distinto. Al
igual que otros lenguajes, FIPA ACL tambin se basa en la teora del acto del habla.
2.6.3 Protocolos de Interaccin para Agentes (AIP)
Para establecer una comunicacin entre agentes es necesario definir previamente el
protocolo o acuerdo que van a seguir durante la conversacin. Un protocolo es una descripcin
detallada del tipo y orden de los mensajes a utilizar, la cual considera adems aspectos como
las restricciones en el contenido de esos mensajes [Odell et al., 2003].
FIPA posee una lista de protocolos para la interaccin entre agentes, los cuales son
expresados mediante AUML (Agent Unified Model Language). AUML es un lenguaje de
representacin de protocolos mediante la adopcin de UML. Para esto hace uso de una serie
de herramientas de desarrollo ya existentes (CASE) orientndolas especficamente al campo
de desarrollo de agentes.
En los diagramas de protocolos utilizados por AUML se pueden identificar una serie de
elementos [Bauer et al., 2001]:
a) Roles de Agentes: Identifica uno o ms roles para cada agente involucrado.
b) Lneas de vida de agentes e hilos de iteracin: La lnea de vida de un agente define el
periodo de tiempo en el cual un agente existe, comenzando su vida cuando este se crea
y finalizndola cuando este se destruye. Por otra parte los hilos de iteracin muestran
el periodo de tiempo en el cual un rol de agente est realizando alguna tarea.
c) Protocolos anidados y entrelazados: Los protocolos anidados se utilizan para definir
protocolos que se encuentran dentro de otros protocolos, mientras que los protocolos
entrelazados se utilizan para realizar acciones que se generan al enlazar dos o ms
protocolos.
vietas

22
d) Semntica de mensajes: Se extiende la semntica de los mensajes UML con el fin de
poder representar sin limitaciones la comunicacin entre agentes.
e) Entrada y salida de parmetros por protocolos anidados: Los parmetros de entrada de
los protocolos anidados son hilos de interaccin que se llevan a cabo desde fuera del
protocolo hacia adentro, mientras que los parmetros de salida son hilos de interaccin
que se inician desde dentro del protocolo anidado y se llevan hacia afuera.
f) Plantillas de protocolos: El propsito de las plantillas de protocolos es crear patrones
reutilizables de instancias de protocolos tiles.
2.6.3.1 FIPA IPs
FIPA Interaction Protocols (IPs) especifica una serie de protocolos pre-establecidos para
el intercambio de mensajes ACL. Algunos de ellos son [Mas, 2005]:
Request: Permite a un agente solicitar a otro que realice una determinada accin.
Query: Permite a un agente solicitar a otro que informe sobre algo.
Request When: Permite a un agente solicitar a otro que realice una determinada accin
cuando se cumpla una pre-condicin.
Contract Net: Un agente toma el papel de gestor para que se realice una determinada
tarea por uno o varios agentes, donde cada uno de los agentes interesados ofrecen sus
servicios. El agente gestor es el encargado de determinar el/los agentes que realizarn
finalmente la tarea.
Iterated Contract Net: Este protocolo se basa en el anterior Contract Net, con la
diferencia que se pueden realizar varias rondas de ofertas.
Subasta Inglesa: Los agentes participan de una subasta en la que se fija un precio bajo
y se va aumentando gradualmente.
Subasta Holandesa: Los agentes participan en una subasta en la que se fija un precio
alto y se va disminuyendo gradualmente.
Brokering: Agente encargado de realizar tareas de intermediario en sistemas de
mediacin y Sistemas Multiagente.
Recruiting: Parecido al brokering, con la diferencia que las respuestas sobre el servicio
van directamente al agente que lo necesita (sin pasar por el broker).
Subscribe: Un agente pide ser notificado hasta que una determinada accin se cumple.

23
Propose: Un agente iniciador propone la realizacin de una determinada tarea a un
grupo de agentes, los cuales pueden aceptar o rechazar dicha propuesta.
2.7 Metodologas de Desarrollo de Agentes
Debido a la dificultad que existe al momento de querer representar cada uno de los
elementos que componen un Sistema Multiagente, han surgido una serie de metodologas que
tienen como finalidad otorgar tcnicas, herramientas y mtodos para el desarrollo de agentes.
A continuacin se vern las metodologas de desarrollo de agentes ms utilizadas:
2.7.1 MaSE
Multiagent Systems Engineering (MaSE), es una metodologa de propsito general para
el desarrollo de Sistemas Multiagente basados en los principios de la Ingeniera de Software,
la tecnologa orientada a objetos, entre otras [Wood y DeLoach, 2001]. MaSE divide el
proceso de desarrollo en dos grandes fases: la fase de anlisis y la fase de diseo, como puede
observarse en la Figura 2.6.
La fase de anlisis considera tres etapas:
1) Captura de objetivos: Se identifican y estructuran los objetivos, construyendo de esta
forma el Goal Hierarchy Diagram (GHD).
2) Aplicar casos de uso: Se crean diagramas de secuencia a partir de los casos de uso
obtenidos de los requerimientos iniciales del sistema.
3) Refinar Roles: Esta etapa se divide en dos sub-etapas: La creacin del modelo de roles
y la especificacin del comportamiento de las tareas.
La fase de diseo considera cuatro etapas:
1) Crear las clases de agentes: Se determina la arquitectura total del Sistema Multiagente
en trminos de agentes y las conversaciones que estos realizan.
2) Construir conversaciones: El diseador establece los protocolos de coordinacin entre
los agentes.
3) Ensamblar clases de agentes: Se crea la arquitectura interna de las clases de agentes.
4) Diseo del sistema: Se crean instancias de todas las clases de agentes en un agente real,
esto mediante la utilizacin de un diagrama de implementacin.
vietas
vietas

24

Figura 2.6 Etapas de desarrollo en MaSE [Wood y DeLoach, 2001]
2.7.2 GAIA
GAIA es una metodologa de desarrollo que ha sido realizada especficamente para el
anlisis y diseo de sistemas basados en agentes. En particular, esta metodologa alienta a los
desarrolladores a construir sistemas basados en agentes con un diseo organizacional. Al igual
que MaSE, esta se divide en la fase de anlisis y la fase de diseo [Garro, 2012], modelo que
puede verse ms claramente en la Figura 2.7.

25

Figura 2.7 Modelo GAIA [Garro, 2012]
El objetivo de la fase de anlisis es desarrollar una comprensin del sistema y su
estructura, esta comprensin se obtiene a partir del sistema de organizacin. Una organizacin
puede ser vista como una coleccin de roles que se relacionan entre s, con patrones de
interacciones entre otros roles bien definidos. Los dos modelos utilizados en GAIA para la
fase de anlisis son: el modelo de roles y el modelo de interacciones.
a) El modelo de roles identifica los roles clave del sistema los cuales poseen determinadas
responsabilidades y permisos.
b) El modelo de interacciones consiste en un set de definiciones de protocolos para cada
tipo de interaccin que exista entre los diferentes roles.
La fase de diseo por otra parte implica generar tres modelos: el modelo de agente, el
modelo de servicios y el modelo de conocimiento.
a) El modelo de agente identifica los tipos de agentes que componen el sistema y las
instancias de agentes que se pueden crear a partir de estos.
b) El modelo de servicios identifica los principales servicios que se requieren para que los
roles de agentes puedan realizar su funcionalidad.
c) El modelo de conocimiento documenta las lneas de comunicacin entre los diferentes
agentes.
2.7.3 PASSI
PASSI (Process of Agent Societies Specification and Implementation) es una
metodologa paso a paso para el diseo y desarrollo de sociedades Multiagentes [Burrafato y
Cossentino, 2002]. PASSI integra los modelos de diseo y conceptos de la Ingeniera de
vietas
vietas

26
Software Orientada a Objetos y los enfoques de la Inteligencia Artificial. Se utiliza UML
como lenguaje de modelado, debido a su amplia aceptacin y capacidad de extensin.

Figura 2.8 Modelos de la metodologa PASSI [Burrafato y Cossentino, 2002]
El proceso de diseo de PASSI se compone de cinco modelos, los cuales pueden ser
divididos en doce fases de construccin de Sistemas Multiagente. A continuacin se describen
cada uno de ellos [Burrafato y Cossentino, 2002]:
a) Modelo de Requerimientos del Sistema. Es una representacin antropomrfica de los
requisitos del sistema, se compone de cuatro pasos:
Descripcin del Dominio (D.D): Entrega como resultado una descripcin
funcional del sistema compuesto por una serie de diagramas de casos de uso
convencionales.
Identificacin de Agentes (A.Id): Esta fase se obtiene a partir de los diagramas
casos de uso de la D.D. Se crea una separacin de las responsabilidades de cada
agente del sistema mediante la utilizacin de paquetes UML.
Identificacin de Roles (R.Id): Identifica todos los caminos posibles en la
comunicacin entre agentes como tambin la comunicacin inter-agente. Un
camino describe un escenario de interaccin que trabaja para lograr una tarea
especfica en el sistema. Esto se representa mediante la utilizacin de
diagramas de secuencia.
Especificacin de Tareas (T.Sp): Se realiza un diagrama de actividad por cada
agente del sistema, compuesto principalmente por dos calles. La calle del lado
derecho contiene un conjunto de actividades que representan las diversas tareas

27
del agente, mientras que la calle del lado izquierdo contiene algunas actividades
que representan las interacciones entre otros agentes.
b) Modelo de Sociedad de Agentes. Un modelo de las interacciones sociales y
dependencias de los agentes que la conforman. El desarrollo de este modelo se
compone de tres pasos:
Descripcin de la Ontologa (O.D): Se describe la sociedad de agentes teniendo
en cuenta el punto de vista ontolgico. Se hace uso de diagramas de clase para
representar el conocimiento de los agentes y la pragmtica de sus acciones.
Descripcin de Roles (R.D): Se modela el ciclo de vida de un agente mediante
diagramas de clases, teniendo en cuenta sus funciones, colaboraciones y las
conversaciones en que est involucrado. Se introducen normas sociales de la
sociedad de agentes, como tambin leyes de comportamiento.
Descripcin de Protocolos (P.D): Se utilizan diagramas de secuencia,
generalmente en lenguaje AUML para especificar los protocolos utilizados en
las comunicaciones en trminos de performatives.
c) Modelo de Implementacin de Agentes. Un modelo de la solucin de la arquitectura en
trminos de clases y mtodos, este se compone de dos pasos:
Definicin de Estructura de Agentes (A.S.D): Se hace uso de diagramas de
clases para representar la estructura de la solucin, tanto del Sistema
Multiagente como de los agentes individuales.
Descripcin del Comportamiento de Agentes (A.B.D): Se hace uso de
diagramas de actividad para mostrar el flujo de eventos entre y dentro de las
principales clases de agentes y sus clases internas (en representacin de sus
tareas).
d) Modelo de Cdigo. Un modelo de la solucin a nivel de requerimientos de cdigo, este
modelo produce los siguientes dos pasos :
Reutilizacin de Cdigo (C.R): En esta fase se intenta reutilizar patrones
existentes de agentes y tareas. Considerando tanto patrones de cdigo como
tambin de diseo.
Cdigo Completo (C.C): En esta fase se realiza el trabajo clsico de un
programador, el cual hace uso de los diferentes diagramas del diseo para
completar el cdigo de la aplicacin.

28
e) Modelo de Despliegue. Modelo de la distribucin de las partes de un sistema, este
modelo se compone de un solo paso:
Configuracin de Despliegue (D.C): Se hace uso de diagramas de despliegue
para representar la posicin de los agentes en sistemas distribuidos o ms
generalmente en contextos de agentes mviles.
2.8 Plataformas de Desarrollo de Agentes
Se han creado muchas plataformas con el fin de facilitar el trabajo de interconexin y
ejecucin de los agentes en Sistemas Multiagente. Estas bsicamente permiten a los
desarrolladores abstraerse de ciertas rutinas y centrarse especficamente en los requerimientos
del software ms que en su implementacin. A continuacin se ver la plataforma JADE,
principalmente por ser una de las ms utilizadas en el desarrollo de agentes, adems de ser la
plataforma escogida para este proyecto.
2.8.1 JADE
JADE (Java Agent Development Environment) es una plataforma de software
completamente implementada en Java. Esta plataforma simplifica el desarrollo de Sistemas
Multiagente a travs de un middleware que cumple con las especificaciones FIPA y una serie
de herramientas grficas que ayudan en las tareas de depuracin e implementacin del
programa. El objetivo de JADE es simplificar el desarrollo de agentes y a su vez garantizar el
cumplimiento del estndar FIPA. Para lograr este objetivo, JADE ofrece una gran una serie de
caractersticas a los programadores de agentes, entre algunas de ellas se destaca [Bellifemine
et al., 2001]:
Plataforma de agentes conforme a las especificaciones FIPA, que incluye tres agentes
de forma predeterminada: el AMS (Agent Management System), el DF (Directory
Facilitator), y el ACC (Agent Communication Channel). Cada uno de estos se activa
cuando JADE comienza.
Plataforma de agentes distribuidos, siendo posible trabajar en una red compuesta por
diversos host.
Un nmero adicional de DFs conformes a las especificaciones FIPA para la creacin
de entornos multi-dominios, donde cada dominio es un conjunto lgico de agentes,
cuyos servicios se anuncian a travs de un DF comn.
Una API Java para el envo y recepcin de mensajes ACL hacia o desde otros agentes.
Un protocolo para la conexin de diferentes tipos de plataformas.

29
Transporte liviano de mensajes ACL dentro de una misma plataforma, los cuales
pueden ser codificados para evitar ser empaquetados y desempaquetados.
Una librera de IPs FIPA listos para ser utilizados.
Soporte para la movilidad de agentes en computadores que posean la plataforma
JADE.
Libreras para administrar ontologas y lenguajes definidos por el usuario.
Una interfaz grfica para administrar muchos agentes y plataformas desde el mismo
agente, facilitando todo el proceso de implementacin y depuracin.
Con formato: Sangra:
Izquierda: 0,63 cm
vietas

30

Captulo 3: Motores Grficos 3D
3.1 Qu es un Motor Grfico?
Un motor grfico es la pieza fundamental de las aplicaciones que trabajan con grficos
bidimensionales o tridimensionales. Este se encarga de administrar y actualizar en tiempo real
cada uno de los elementos que componen el entorno.
Existen una gran cantidad de motores que no solo realizan el apartado grfico visible por
pantalla, sino que incorporan adems una serie de otros mdulos necesarios para otorgarle
mayores capacidades y realismo a lo que se desea representar, como son: la reproduccin de
sonidos y videos, manejo de fsicas, uso de dispositivos de entrada y salida, deteccin de
colisiones, entre otros.
A pesar que la mayora de los motores grficos son utilizados para la creacin de
videojuegos, esto no impide que se puedan crear otro tipo de aplicaciones que requieran
mostrar algo ms que una interfaz de monitoreo al usuario.
3.2 APIs Grficas
La mayor parte de los motores grficos utilizan un conjunto de interfaces de
programacin de aplicaciones (APIs), las cuales bsicamente otorgan una serie de funciones y
procedimientos de uso general que permiten abstraerse de ciertas rutinas que por lo general
deben programarse a bajo nivel. En esencia, una API define sentencias reutilizables que
permiten modularizar funcionalidades que son finalmente incorporadas a las aplicaciones
[Reddy, 2011]. Especficamente las APIs grficas estn destinadas nicamente al manejo de
grficos representados por pantalla, estas interfaces se encuentran limitadas a las capacidades
de hardware que posea el computador en el que se est desarrollando la aplicacin.
Existen dos tipos de APIs grficas, las de propsito especfico y las de propsito general.
Las APIs de propsito especfico se utilizan principalmente para la creacin de aplicaciones
destinadas a quienes deseen mostrar imgenes sin preocuparse del procedimiento necesario
para producir dicha imagen, por otro lado, las APIs de propsito general estn destinadas
principalmente a programadores que necesiten hacer uso de funciones a un nivel de
abstraccin menor [Hearn y Baker, 2005].
A continuacin se describirn las dos interfaces de programacin grfica ms
importantes que existen actualmente en el mercado: OpenGL y Direct3D.

31

3.2.1 OpenGL
El sistema grfico OpenGL (Open Graphics Library) es una interfaz de software para
hardware grfico originalmente creada por Silicon Graphics Incorporated (SGI), esta permite
la creacin de programas interactivos que requieren mostrar grficos 2D y 3D en tiempo real
[Shreiner et al., 2008], [Maroto, 2005]. Algunas de las principales caractersticas que hacen de
OpenGL una fuerte alternativa a considerar al momento de escoger una API grfica son: su
gran potencial, su interfaz independiente del hardware, su simplicidad y su eficiencia.
Existe una gran cantidad de reas en las cuales se ha utilizado el uso de esta API para el
desarrollo de aplicaciones grficas 3D, como son: los videojuegos, pelculas, simulaciones,
hasta visualizaciones para uso cientfico, mdico, comerciales, entre otros [Wright y Lipchak,
2004]. Actualmente es reconocido como estndar sobre grficos computacionales, siendo
adems uno de los ms utilizados en el mundo.
sta API posee una gran cantidad de funcionalidades, tales como el soporte de luces y
sombras, mapeado de texturas, transparencia, animacin de modelos, soporte de nieblas,
texturas con profundidad, etc. [Wright et al., 2007].
Las partes que componen la escena grfica en OpenGL son construidas a partir de
primitivas geomtricas bsicas, como cubos, esferas, pirmides, etc., las cuales luego son
convertidas mediante funciones matemticas a un conjunto de pixeles (elemento visible ms
pequeo de una imagen). Finalmente estos pixeles se proyectan sobre un plano bidimensional,
el cual puede ser por ejemplo el rea de visualizacin de un monitor de computador [Hearn y
Baker, 2005].
3.2.2 Direct3D
Direct3D es una de las APIs que posee DirectX, utilizada principalmente en el sistema
operativo Microsoft Windows y consolas como Xbox y Xbox 360. Esta API se encarga de
todo el procesamiento grfico necesario para poder visualizar imgenes 3D por pantalla. Una
de las caractersticas de esta API, es que trabaja directamente con el hardware grfico, a
diferencia de otras interfaces de dispositivos grficos, aumentando de esta forma el
rendimiento considerablemente [Thomson, 2006].
Adems esta API fue diseada para tener fcil acceso a las caractersticas avanzadas 3D
del hardware grfico, creando una capa de abstraccin la cual otorga una interfaz para el
programador independiente del hardware [Engel y Geva, 2000].
Eliminado:

32
Actualmente es utilizada por grandes motores de videojuegos como UDK (Unreal
Development Kit) o CryEngine, esto debido principalmente a su capacidad de crear escenas
realistas con gran cantidad de detalles y en tiempo real de ejecucin.
3.3 Representacin Tridimensional de Geometras
En 3D, las superficies estn construidas a partir de un conjunto de polgonos, los cuales
son creados y unidos entre s. La unin de cada uno de estos polgonos conforman la
superficie de una figura, a la cual se le denomina modelo 3D [Hess, 2010].

Figura 3.1 Elementos bsicos de una geometra [Elab. Propia]
Toda geometra de un modelo 3D se compone bsicamente de tres elementos (Figura
3.1), los cuales son [Ezequiel, 2004]:
Polgonos: Conforman la superficie a representar. Todos los polgonos en los modelos
3D deben ser cncavos, es decir, cada uno de sus ngulos interiores debe ser menor a
180.
Aristas: Segmentos o lados de un polgono, estos unen dos vrtices consecutivos del
modelo.
Vrtices: Puntos extremos de las aristas, estos poseen diferentes tipos de informacin,
los cuales pueden ser:
Un identificador: Para localizar y diferenciar el vrtice de los dems vrtices en
el entorno.
Posicin en el mundo 3D: Representado mediante coordenadas (x, y, z).
Coordenadas de textura: Utilizadas para ubicar correctamente una imagen de
textura en la geometra del modelo.
Un vector normal: Perpendicular al plano que forma el polgono, utilizado para
determinar tanto la direccin del vector, como la del polgono.

33
Color e informacin de iluminacin: Necesario para generar los clculos de
transformacin, iluminacin y color.
Parmetros de Skinning: Para crear una relacin entre el vrtice y los huesos del
modelo, necesario para crear las animaciones del objeto.
Las GPU (Graphics Processing Unit) que poseen las tarjetas grficas, se han
especializado en operaciones sobre tringulos, por lo cual es necesario en muchas ocasiones
convertir los modelos 3D formados por polgonos con una cantidad mayor a tres vrtices a
modelos conformados nicamente por polgonos de tres vrtices, proceso que por lo general es
realizado por el motor grfico o la herramienta de modelado que se est utilizando, siendo
totalmente transparente para el diseador.
Se debe considerar que el trabajar con superficies triangulares no impide el disear
figuras con una calidad superior, ya que todos los polgonos pueden reducirse hasta su
representacin mnima (3 vrtices), como puede ser el cuadrado, compuesto por dos tringulos
(ver Figura 3.2 (a)), o figuras ms complejas, mediante la utilizacin de vrtices en comn
para la creacin de superficies triangulares (ver Figura 3.2 (b))

Figura 3.2 Ejemplo polgonos con tringulos [Ezequiel, 2004]
En muchas ocasiones, se utiliza un conjunto de primitivas geomtricas bsicas como
punto de partida al momento de modelar una superficie, en este caso, se considera la
semejanza que estas posean con lo que se desea crear. La cantidad de primitivas disponibles
depende de la herramienta de modelado que se utilice. En la Figura 3.3 se pueden observar
algunas de las primitivas bsicas ms conocidas.

34

Figura 3.3 Primitivas geomtricas bsicas [Elab. Propia]
3.4 Tcnicas Utilizadas por Motores Grficos 3D
El realismo del entorno en las aplicaciones es un factor clave para la aceptacin por
parte de los usuarios, crendoles la sensacin de estar situados realmente en el lugar y formar
parte de este. Existen muchas formas de aumentar el realismo, una de ellas es incrementar la
complejidad de los diferentes elementos que conforman la escena, sin embargo, esto significa
aumentar la cantidad de clculos y tiempo de procesamiento necesario por parte de las tarjetas
grficas para generar la imagen final, teniendo como resultado un decremento en la fluidez y
movimiento de la escena, adems de la perdida de atencin por parte de los usuarios. Los
motores grficos utilizan una serie de tcnicas que buscan aumentar el realismo, pero sin
perder de vista el rendimiento y la fluidez de la escena. A continuacin se vern algunas de las
tcnicas utilizadas, las cuales en su mayora se obtuvieron a partir de [Ezequiel, 2004].
3.4.1 Renderizado
Proceso por el cual se genera una imagen por pantalla a partir de cada uno de los
elementos que componen la escena en un determinado momento. En el caso de los grficos
3D, el proceso de renderizado se realiza en el pre-renderizado o en tiempo real. El pre-
renderizado es un proceso intensivo que es tpicamente utilizado en las pelculas, mientras que
el renderizado en tiempo real, es utilizado en el desarrollo de videojuegos basados en el uso de
tarjetas grficas [Gregory, 2009].
3.4.2 VSync
La sincronizacin vertical (VSync), es una funcin que sirve para sincronizar el nmero
de frames generados por la tarjeta grfica con la tasa de refresco de la pantalla. Esto previene
la aparicin de defectos visuales, como la desaparicin de elementos en la escena, parpadeos,
movimientos bruscos, entre otros. Este problema surge debido a que generalmente las tarjetas

35
grficas son capaces de generar una gran cantidad de imgenes por segundo, superando
considerablemente la cantidad aceptada por parte de los monitores.

Figura 3.4 Ejemplo de error en sincronizacin de frames [URL 3, 2012]
3.4.3 rboles BSP
La particin binaria del espacio (BSP) es un mtodo para subdividir recursivamente el
espacio en elementos convexos utilizando planos. Esta subdivisin permite representar la
escena mediante la estructuracin de datos en un rbol, conocido como rbol BSP. Una de las
funcionalidades de esta estructuracin, es la organizacin de los polgonos del modelo de
forma jerrquica respecto a representacin de las posiciones en el espacio [Gmez et al.,
1999]. En la Figura 3.5 se puede observar como a partir de un polgono se va generando el
rbol BSP, subdividiendo la superficie poco a poco mediante planos, obteniendo como
resultado polgonos cncavos.

Figura 3.5 Ejemplo rbol BSP [URL 4, 2011]
3.4.4 Antialiasing
El aliasing, es el efecto de dentado producido al generar lneas en ngulos cercanos a
lneas verticales u horizontales. Estas irregularidades son causadas por la cuadrcula de pixeles
que utilizan las pantallas, en las cuales se almacenan los pixeles de forma exacta. La tcnica

36
denominada antialiasing, busca reducir o eliminar esta distorsin, como en el ejemplo que
puede observarse en la Figura 3.6.

Figura 3.6 Ejemplo imagen con y sin antialiasing [Ezequiel, 2004]
Existen diferentes tcnicas para implementar el Antialiasing en los motores grficos, las
cuales varan en calidad y rendimiento. Algunas de ellas se basan en transformar la imagen a
una resolucin mayor, para luego mostrarla en una resolucin menor, proceso que requiere un
gran esfuerzo de procesamiento grfico. Otra forma es difuminar los bordes de las lneas para
as engaar el ojo humano, dando la sensacin de suavizado, como puede observarse en la
Figura 3.6. Actualmente existen tcnicas mucho ms eficientes, como por ejemplo el
Quincuix, Antialiasing 2x, 4x, 6x, 8x, Accuview, FXAA, entre otras. Todas ellas con el fin de
eliminar el efecto de dentado en las imgenes [Ezequiel, 2004].
3.4.5 Iluminacin y Transformacin (T&L)
La transformacin, consiste en la conversin de coordenadas en el espacio. Esta puede
ser utilizada para el movimiento de los diferentes objetos 3D de la escena, como tambin para
la conversin de coordenadas 3D a las coordenadas 2D de la pantalla (ver Figura 3.7).

37

Figura 3.7 Proceso de transformacin de coordenadas 3D a 2D [URL 5, 2000]
Por otra parte, la iluminacin se utiliza para determinar el brillo en los objetos 3D, ya
sea de forma leve o radical. Para iluminar objetos existen dos formas principalmente: la
iluminacin difusa y la iluminacin especular. La iluminacin difusa es aquella que incide
sobre un objeto y se dispersa de igual forma en todas las direcciones, sin depender de la
posicin en que se encuentre el espectador, ni la direccin de la luz; un ejemplo de este tipo de
luz es sol. La iluminacin especular, por el contrario, depende de la posicin del espectador, la
direccin de la luz y la forma de la geometra en que se est reflejando. En la Figura 3.8 se
puede observar un ejemplo de ambos tipos de luces.
Es importante mencionar que debido a la gran cantidad de clculos y procesamiento que
se requiere para realizar tanto la iluminacin, como la transformacin en una escena, se utiliza
hardware especializado para los clculos, especficamente GPU, liberando de esta forma el
procesamiento realizado por la CPU.

Figura 3.8 Ejemplo tipos de luces [Ezequiel, 2004]

38
3.4.6 Sombreado
La mayor parte de las fuentes de luz, producen sombra al direccionarlas sobre un
determinado objeto. Adems de aumentar el realismo en la escena, las sombras tambin
ayudan a la comprensin del entorno por parte del espectador, el cual capta mucha
informacin de forma inconsciente, como es por ejemplo: la profundidad de los objetos, la
distancia respecto a otros, la intensidad de la luz, etc.
Para la implementacin de las sombras, han surgido una serie de tcnicas, cada una con
sus ventajas y desventajas. Una de las tcnicas ms utilizadas es el denominado Mapeo de
Sombras (Shadow Map). El mapeo de sombras tradicional se basa en algoritmos de superficie
visible en el z-buffer, el cual es una especie de administrador de la imagen respecto a la
profundidad de sus coordenadas en la escena, utilizado mapas de profundidad para luego
calcular las sombras, como puede observarse en la Figura 3.9.

Figura 3.9 Ejemplo de shadow map [Ahokas, 2002]
3.4.7 Niveles de Detalle (LODs)
Generalmente, una escena 3D est compuesta por una gran cantidad de polgonos, los
cuales en muchas ocasiones no son percibidos completamente por el usuario [URL 6, 2009].
Para mejorar la eficiencia de las aplicaciones, se sugiri utilizar versiones ms simples de
geometra para elementos que no tienen una gran relevancia visual en determinados
momentos, por ejemplo, geometras que se encuentran muy lejos de la visin del usuario (ver
Figura 3.10).

39

Figura 3.10 Ejemplo de diferentes tipos de LODs [URL 6, 2009]
3.4.8 Vertex, Geometry y Pixel Shaders
Tanto OpenGL como Direct3D poseen sus propios lenguajes de Shaders (efectos de
Renderizado). Por una parte existe GLSL (OpenGL Shading Language) de OpenGL y por otra
parte HLSL (High Level Shader Language) de Direct3D, adems existe Cg, el lenguaje de
Shader de Nvidia. Estos lenguajes trabajan mediante la utilizacin de tres elementos: Vertex
Shaders, Geometry Shaders y Pixel Shaders [Engel et al., 2008]:
a) Los Vertex Shaders, son herramientas para la modificacin de los vrtices de un
modelo, realizando sobre estos, operaciones matemticas para definir colores, luces y
texturas. Adems, con los Vertex Shaders se pueden realizar transformaciones a la
geometra del modelo, obteniendo como resultado en algunos casos animaciones
complejas, efectos de onda, generacin de niebla, entre otros.
b) Los Geometry Shaders, son tcnicas para la creacin de nuevas primitivas, por
ejemplo: puntos, lneas o tringulos. Estos se aplican luego de la utilizacin de los
Vertex Shaders.
c) Los Pixel Shaders, son utilizados para trabajar con los pixeles de las imgenes
generadas al final del proceso de renderizado, estos se aplican luego de los Geometry
Shaders y los Vertex Shaders.

3.4.9 Radiosity
Esta tcnica se utiliza para el clculo de iluminacin global en ambientes cerrados. La
radiosidad busca resolver las interacciones de las luces que se producen en la escena, adems
de encontrar un equilibrio entre la energa producida por los objetos emisores de luz y la
energa absorbida por los objetos en el entorno [Rodrguez et al., 2003]. La radiosidad
vietas

40
considera los componentes de luz reflexiva en las superficies, los cuales pueden iluminar las
superficies que se encuentran a su alrededor. En la Figura 3.11 se puede observar, como la luz
proveniente desde el techo ilumina a los polgonos que no se encuentran necesariamente en su
direccin, esto debido principalmente a la capacidad de absorcin y reflexin de las dems
superficies que componen la escena.

Figura 3.11 Ejemplo de radiosidad [URL 7, 2012]
3.5 Listado de Motores Grficos 3D
A continuacin se describirn algunos de los motores grficos ms utilizados para la
implementacin de entornos en 3D en tiempo real:
Irrlicht Engine:
Irrlicht es un motor de videojuegos de cdigo abierto desarrollado por Nikolaus
Gebhardt. Este motor utiliza las APIs grficas Direct3D, OpenGL y el software de render
Irrlicht para la generacin de entornos de alto rendimiento en tiempo real [URL 8, 2012].
Algunas de las caractersticas destacables de este motor son: su independencia de la
plataforma, la utilizacin de Shaders GLSL y HLSL, animacin de personajes, una gran
cantidad de formatos soportados, utilizacin de z-buffer, LODs, generacin de efectos
especiales mediante partculas, entre otros. Las plataformas soportadas son: Windows, Linux,
OSX, Solaris y plataformas que soporten SDL (Simple Direct Library).
Panda 3D:
Desarrollado por Disney, es un motor de cdigo abierto y libre, bajo la licencia BSD
[URL 9, 2012]. El lenguaje de programacin para el cual fue destinado Panda3D es Python,
aunque tambin se encuentra una versin disponible para C++. Las APIs grficas utilizadas
por este motor son OpenGL y Direct3D.

41
Algunas caractersticas del motor son: implementacin de una GUI propia, soporte para
inteligencia artificial (PandaAI), herramientas de depuracin, efectos de partculas, soporte de
fsicas de Nvidia (PhysX), Shadow Mapping, lenguajes de Shaders Cg y GLSL, entre otros.
OGRE 3D:
OGRE 3D (Object-Oriented Graphic Rendering Engine) es un software libre
desarrollado por el equipo OGRE y licenciado bajo MIT [URL 10, 2012]. Actualmente OGRE
3D es considerado como una de las mejores APIs de alto nivel para el desarrollo de
aplicaciones 3D. Tiene soporte OpenGL y Direct3D, adems de funcionar en las plataformas
Windows, Linux y Mac OS X.
Algunas de las caractersticas ms destacables de este motor, son su amplia comunidad,
su gran cantidad de documentacin, soporte para animaciones, LODs, lenguajes de Shaders
Cg, HLSL y GLSL, entre otros.
Crystal Space:
Crystal Space es un framework desarrollado en C++ y OpenGL por Jorrit Tyberghein
[URL 11, 2012]. Este es un software de cdigo abierto licenciado bajo LGPL. Crystal Space
funciona en las plataformas Windows, GNU/Linux y Mac OS X. Algunas caractersticas son:
lenguaje de Shaders Cg, BSP, un administrador de la escena (objetos organizados
jerrquicamente), soporte de animacin y sonidos, Light Maps, soporte para dispositivos de
I/O, LODs, entre otros.
Unity 3D:
Unity es un motor grfico 3D en tiempo real, especficamente dedicado a la creacin de
videojuegos [URL 12, 2012]. Este motor est disponible para Windows y Mac OS X; y
permite ser portado a una gran cantidad de plataformas, de las cuales se encuentran Windows,
Mac, Xbox 360, PlayStation 3, Wii, iPad, iPhone, y Android. Unity es desarrollado por Unity
Technologies/Unity Team, teniendo una licencia propietaria y una gratuita.
Este motor posee una gran cantidad de caractersticas, como la capacidad de crear
aplicaciones en red, el soporte de fsicas de PhysX de Nvidia, reproduccin de sonidos y
msica, LODs, Light Mapping, algoritmos para el seguimiento de rutas (Path Finding), un
generador de terrenos, un set de herramientas de depuracin y programacin, soporte de
lenguajes de scripting (JavaScript, C#, y un lenguaje de Python llamado Boo), lenguajes de
Shader Cg, GLSL y HLSL, entre otros.
Unreal Engine:
Unreal Engine es un motor grfico 3D para computador y consolas bajo licencia libre,
desarrollado por la compaa Epic Games [URL 13, 2012]. Este se implement por primera

42
vez en el juego Unreal en 1998, siendo la base para muchos juegos en adelante. Unreal Engine
utiliza las APIs grficas OpenGL y Direct3D. Est escrito en C++, por lo que es compatible
con varias plataformas de computador (Windows, GNU/Linux, Mac OS, Mac OS X), y una
gran cantidad de consolas (Gamecube, Wii, Xbox 360, PlayStation 3, entre otros).
Unreal Engine, al igual que Unity 3D, ofrece una gran cantidad de herramientas para los
desarrolladores, como el FaceFX studio, para las creacin de animaciones faciales realistas a
partir de sonidos; el Speed Tree Foliage Editor, para la creacin de rboles animados en
tiempo real; el UnrealScript, un lenguaje de scripting para la programacin de los juegos en
Unreal, entre muchas otras. Algunas de las caractersticas de este motor son: renderizado en
sectores, rboles BSP, LODs, deteccin de colisiones, Light Maps, Shaders, Radiosidad, entre
otros.
jMonkeyEngine:
Java Monkey Engine (jME), es un motor grfico libre, bajo licencia BSD, orientado al
desarrollo de aplicaciones en 3D [URL 14, 2012]. jME es actualmente uno de los motores ms
completos escritos en Java, con una gran cantidad de colaboradores y una completa
documentacin. La API grfica utilizada por este motor es OpenGL, pero debido a su capa de
abstraccin, permite que cualquier API de renderizado pueda incorporarse como un plugin.
LWJGL y JOGL ya estn incorporadas.
jME se basa en una arquitectura de escenas, las cuales se estructuran como un rbol, es
decir, se almacena la informacin en nodos, los cuales pueden tener cualquier cantidad de
nodos hijos, pero cada hijo puede tener solo un padre. Esto permite un recorrido mucho ms
sencillo y rpido de la informacin, descartando de esta forma algunas ramas que son
innecesarias. La geometra final de la escena 3D se encuentra ubicada en los nodos hojas
(nodos extremos del rbol).
Este motor grfico posee un complejo kit de desarrollo de software (SDK) para facilitar
la tarea de desarrollo y depuracin. Una de las herramientas disponibles en este kit, es la slida
plataforma de desarrollo denominada jMonkeyPlatform, la cual entrega una interfaz de alto
nivel basada en el conocido IDE Netbeans de Oracle. Otra de las caractersticas del SDK, es la
estructuracin de cada uno de los elementos que conforman la escena mediante assets, los
cuales pueden ser instanciados fcilmente en la fase de programacin.
Captulo 4: Modelado 3D
4.1 Tcnicas de Modelado
Actualmente existe una amplia gama de posibilidades a la hora de escoger una tcnica
de modelado, la mejor tcnica depende muchas veces de lo que se desea realizar. Cabe

43
destacar, que las diversas tcnicas de modelado pueden utilizarse en conjunto para la creacin
de un solo modelo 3D. A continuacin se mostrarn algunas tcnicas para la creacin de
modelos 3D.
4.1.1 Modelado Poligonal
Esta es una de las tcnicas ms utilizada, principalmente por su rapidez y simplicidad a
la hora de crear diversos tipos de superficie. El modelado poligonal consiste en la
modificacin directa de los vrtices, aristas y polgonos de cualquier tipo de geometra. La
ms conocida de esta tcnica es el Box Modeling, o modelado de caja, tcnica que consiste en
la creacin del modelo comenzando con una caja como base. En la Figura 4.1 se puede
observar cmo crear un pie a partir del desplazamiento de los vrtices y la aplicacin de
algunas transformaciones en los polgonos.

Figura 4.1 Ejemplo box modeling [URL 15, 2006]
Esta tcnica resulta ideal para la creacin de modelos que poseen una estructura rgida
inherente, como pueden ser edificios, viviendas, muebles, o algunas superficies que no
requieren de un gran detalle, entre otros.
Una de las principales dificultades de esta tcnica es que se debe decidir la resolucin
que se le dar a la superficie con antelacin, si ms adelante se necesita aumentar la cantidad
de polgonos ser mucho ms complicado.
4.1.2 Modelado mediante Splines
El modelado mediante splines o tambin llamado NURBS Modeling, consiste en la
creacin de modelos 3D a partir del uso de lneas vectoriales en 2D (splines) ubicadas en un
espacio en 3D, a las cuales posteriormente se le aplican transformadores de malla para generar
la superficie de la figura deseada, como puede observarse en el ejemplo de la Figura 4.2.
Con formato: Fuente: 10 pt,
Ingls (Estados Unidos)

44

Figura 4.2 Ejemplo NURBS modeling [URL 16, 2004]
Esta tcnica, a diferencia del Box Modeling, es mucho ms adecuada para la creacin de
superficies orgnicas, es decir, modelos que posean una gran cantidad de superficies curvadas
o con una complejidad media. El principal problema del modelado mediante splines son los
perfiles. Los perfiles son la conexin y ubicacin de las diferentes lneas vectoriales que
compondrn el modelo, mientras ms complejo y curvo sea el modelo, mayor ser la cantidad
de splines que se necesiten. En la Figura 4.3 se puede observar ms claramente el perfil
utilizado para la creacin de una superficie.

Figura 4.3 Utilizacin de un perfil [URL 17, 2011]
4.1.3 Digital Sculpting
Hace algunos aos atrs, algunas aplicaciones para la creacin de modelos 3D solan
prometer la denominada Digital Sculpting o Escultura Digital para referirse a una
interfaz en la cual las herramientas utilizadas para modelar eran tan intuitivas que daba la
sensacin de estar trabajando directamente con arcilla [Keller, 2011].

45
Esta tcnica de modelado bsicamente trabaja con mallas de muy alta resolucin a la que
se le aplican distintos tipos de herramientas para ir dndole forma. En algunos casos los
diseadores deben realizar modelos 3D profesionales pero manteniendo una baja cantidad de
polgonos (Low Poly), una alternativa para lograr este requerimiento es crear el modelo
mediante la tcnica de sculpting, la cual posteriormente se convierte en un mapa de normales y
se asigna al modelo en baja poligonizacin, aproximando de esta forma la gran cantidad de
detalles que posea la malla creada en un comienzo [Gregory et al., 2009].

Figura 4.4 Ejemplo de sculpting [URL 18, 2011]
En la Figura 4.4 se puede observar el proceso por el cual un modelo 3D empieza a tomar
la forma deseada al ir moldendolo y aumentando la cantidad de polgonos. A diferencia de
otras tcnicas de modelado, en el sculpting se puede comenzar a trabajar a partir de un modelo
que ya se encuentra en alta poligonizacin, como puede ser por ejemplo una esfera con
muchas caras.
4.2 Texturizado
El texturizado consiste en el proceso de tomar una superficie y modificar su apariencia
mediante el uso de una imagen, funcin matemtica o cualquier otro origen de datos. A este
origen de datos se le denomina textura. Cada textura est compuesta por un conjunto de
texeles, los cuales son representados mediante una matriz de texeles [Valient, 2001],
[Glassner, 1989]. En la Figura 4.5 se puede observar claramente el cambio que se produce al
aplicar una textura a una superficie en 3D, proceso denominado comnmente como mapeado
de textura.

46

Figura 4.5 Ejemplo mapeado de textura [URL 19, 2008]
Adems hay que considerar que el texturizado es una de las fases ms importantes
cuando se desea modelar un objeto en 3D, esto debido principalmente a que la superficie solo
posee colores planos y en muchas ocasiones es necesario otorgarle un mayor grado de
personalizacin y realismo.
4.2.1 Tcnicas de Texturizado
Existen muchas formas para texturizar una superficie, a continuacin se detallarn
algunas de ellas.
4.2.1.1 Procedurales
Generadas mediante frmulas matemticas, buscan crear representaciones reales de
elementos como: nubes, madera, metales, piedras, etc. Estas texturas pueden crearse a partir de
dos tipos de mapas: mapas geomtricos o mapas aleatorios. Los mapas geomtricos poseen un
patrn bien definido, por lo que no tienen aleatoriedad, mientras que los mapas aleatorios son
impredecibles, pero suelen seguir un patrn regular (ver Figura 4.6).

Figura 4.6 Ejemplo texturas procedurales [URL 20, 2009]

47
A continuacin se describen algunas ventajas y desventajas de la utilizacin de texturas
procedurales [URL 20 2009]:
Son densas: Esto quiere decir que no se pierde nitidez al aumentar la cercana de esta a
la cmara.
Son infinitas: Debido a que se definen para todo el espacio, lo cual es muy til cuando
se debe texturizar modelos con un tamao elevado.
Ocupan poco espacio: Ya que no se almacenan en el disco como las imgenes.
Difciles de crear: Debido a que estas no se dibujan, sino que se crean mediante
algoritmos matemticos.
Requieren un mayor procesamiento: A pesar de liberar el disco duro, la CPU ahora se
debe encargar del procesamiento necesario para generar la textura.
4.2.1.2 Vertex Paint
El Vertex Paint, es una forma sencilla de pintar superficies de un modelo mediante la
manipulacin directa del color en los vrtices [URL 21, 2012].

Figura 4.7 Ejemplo de vertex paint [URL 22 2009]
Actualmente existen diversas herramientas que implementan esta tcnica, esto lo
realizan mediante la utilizacin de diversos pinceles, a los cuales se les pueden aadir
diferentes propiedades, como rugosidad, opacidad, tamao, color, intensidad, etc. En la Figura
4.7 se puede observar la utilizacin de esta tcnica aplicada directamente a una superficie.
4.2.1.3 Texturizado por Imagen

48
Como su nombre lo indica, esta tcnica se basa en la utilizacin de imgenes para
generar la textura de un modelo 3D. Debido a que el tamao de la textura influye directamente
en el rendimiento que tendr posteriormente la aplicacin, es necesario que esta tenga un
tamao lo ms pequeo posible, considerando una proporcionalidad con el nmero de pixeles
que se ocupar en la escena. Para el uso de memoria ms eficiente, es recomendable utilizar
texturas cuadradas, como 32x32, 64x64, 128x128, etc.
La forma en que la imagen se adhiere a la malla, depende del modelo y la imagen que se
utilice. Existen muchas formas de unir la imagen al modelo, una de las ms utilizadas es el UV
Mapping. Esta tcnica consiste en la asignacin de pixeles de la imagen 2D a la superficie del
polgono 3D, mediante coordenadas UV (alternativo de XY). Cuando un modelo es creado
como una malla poligonal utilizando un modelador 3D, las coordenadas UV pueden ser
generadas para cada uno de los vrtices de la malla, si luego el modelo quiere pasarse a un
motor grfico, es necesario que la geometra posea sus respectivas coordenadas UV. En la
Figura 4.8 se puede ver como una imagen con coordenadas UV se aplica a la malla.

Figura 4.8 Texturizado mediante UV Map [URL 23, 2006]
4.3 Listado Softwares de Modelado 3D
A continuacin se describirn algunos de los softwares ms utilizados para la creacin
de modelos 3D:
3D Studio Max:
3D Studio Max es un programa de modelado, animacin y renderizacin en 3D
desarrollado por Autodesk [URL 24, 2012]. La utilizacin de 3D Studio Max permite al
usuario la fcil visualizacin y representacin de los modelos en una intuitiva interfaz, as

49
como su exportacin y salvado en otros formatos distintos a los utilizados por el propio
programa. Este software otorga una serie de herramientas orientadas a diferentes perfiles,
como desarrolladores de videojuegos, creadores de efectos visuales, diseadores de grficos
de movimiento, arquitectos, ingenieros, etc. 3D Studio Max es una de las herramientas ms
utilizadas profesionalmente, debido a su larga trayectoria y potentes capacidades, adems de
ser compatible con una gran cantidad de software externos.
Maya:
Maya es un software de modelado 3D destinado principalmente a la animacin
cinematogrfica [URL 25, 2012]. Al igual que 3D Studio Max, su actual desarrollador es
Autodesk. Maya se caracteriza por su potencia, posibilidades de expansin, personalizacin y
herramientas, adems este software posee el MEL (Maya Embedded Language), cdigo
ncleo de Maya, con el cual se pueden crear diversos scripts y personalizaciones del software.
Este software otorga herramientas para animacin, modelado, simulacin, renderizado,
tcnicas de movimiento, y composicin.
Google SketchUp:
Este software permite la creacin de modelos 3D mediante herramientas intuitivas y
fciles de comprender. Est destinado a cualquier tipo de usuario, gracias a su gran cantidad
de tutoriales, un completo centro de asistencia y a una comunidad global de usuarios. Gracias
a SketchUp, se pueden construir modelos desde cero, o descargar los que se necesiten
mediante la galera disponible en Google [URL 26, 2012].
A diferencia de otros programas de modelado 3D, en SketchUp, todos los modelos 3D
estn formados nicamente de dos elementos: aristas y polgonos. Adems existen
herramientas como el empujar/tirar, el cual permite extruir superficies planas a formas
tridimensionales. Algunas caractersticas de este software son: coloreado directo en la
superficie, dividir el modelo en secciones (para verlo por dentro), utilizacin de capas para
ordenar las figuras, intercambio de informacin con Google Earth (debido a que pertenecen a
la misma familia), entre otros.
Cinema4D:
Desarrollado por Maxon, Cinema4D es un software de creacin de grficos y animacin
3D de nivel profesional [URL 27, 2012]. Algunas caractersticas de este software son:
implementacin de materiales y texturas clsicas y avanzadas, herramientas de animacin,
permite importar y exportar a una gran variedad de formatos de archivo para integrar con
muchos otros software, gran cantidad de posibilidades de iluminacin y sombreado, un
poderoso motor de render, entre otros.
Eliminado: s
Eliminado: s

50
Algunas de las ventajas de Cinema4D son su interfaz altamente personalizable y
flexible, lo cual permite adaptarse a la forma de trabajo del software ms fcilmente; y una
curva de aprendizaje bastante alta (en comparacin con otros tipos de software para la
creacin de modelos 3D).
Zbrush:
Software de Digital Sculpting y pintado de modelos 3D desarrollado por la empresa
Pixologic [URL 28, 2012]. Zbrush se introdujo en el mundo como una aplicacin de arte
experimental con una tecnologa nica, la cual era capaz de crear modelos con una gran
cantidad de detalles y efectos. Los modelos con los cuales se trabaja en este software, son muy
difciles de realizar en los programas convencionales de modelado, debido a su arquitectura
orientada a la implementacin de tcnicas de modelado poligonal.
Un flujo de trabajo tpico, es el crear la base de la geometra del modelo en un programa
de modelado convencional y luego exportarlo a software Zbrush para incrementar la cantidad
de detalles.
Blender:
Blender es un software libre, multiplataforma, y de cdigo abierto. Actualmente es
desarrollado por la Fundacin Blender bajo licencia GPL [URL 29, 2012]. Este software
ofrece un amplio espectro de modelado, animacin, texturizado y video post-processing, todo
esto en un solo paquete. Algunas caractersticas claves de este software son [Hess, 2010]:
Una suite de creacin totalmente integrada, la cual otorga una amplia gama de
herramientas esenciales para la creacin de modelos 3D, entre las que destacan son: la
creacin de modelos mediante tcnicas de modelado convencionales, soporte para
Digital Sculpting, texturizado mediante Vertex Paint, entre otros.
Peculiar interfaz grfica, la cual es completamente flexible y adaptable a los diferentes
requerimientos del usuario.
Multiplataforma, debido a su interfaz grfica basada en OpenGL.
Gran calidad, rpida creacin y eficiente flujo de trabajo.
Gran cantidad de usuarios que utilizan este software.
Tamao ejecutable bastante reducido y de fcil distribucin.
Soporte para la creacin de videojuegos mediante el lenguaje de programacin Python.
Actualmente, Blender es compatible con las plataformas Windows, Mac OS X, Linux,
Solaris, FreeBSD e IRIX.

51

Captulo 5: Seleccin de Sistema Multiagente
Para la integracin de un visualizador tridimensional en un Sistema Multiagente,
primero es necesario seleccionar el problema de estudio. En este proyecto se trabajar sobre
un sistema basado en el problema de transporte de pasajeros, especficamente el Dynamic
Dial-a-Ride Problem (D-DARP) utilizado en [Donoso y Sandoval, 2009]. A continuacin se
explicar en qu consisten estos sistemas.
5.1 Sistemas de Transporte Inteligente
En la actualidad, la funcin de los organismos oficiales y departamentos de transporte
ha evolucionado de manera importante; la labor de estas agencias se ha expandido, ms all de
las tareas de construccin y mantenimiento de la infraestructura necesaria para el transporte, a
encargarse tambin de la operacin de las redes, para lograr mejoras de seguridad, fluidez,
comodidad, eficiencia y confiabilidad. Este cambio se ha debido en gran parte a los diversos
problemas de congestin, seguridad vial, ineficiencia y prdida de productividad que posee la
movilidad. El incumplimiento de los horarios en el transporte pblico, el incremento de los
tiempos de viaje, la contaminacin ambiental y acstica, y los elevados costos del servicio son
algunos de estos problemas. Todo esto produce una disminucin en el bienestar de la
poblacin, adems de importantes prdidas econmicas.
Con el fin de manejar las redes de transporte de manera eficiente, la atencin de las
mismas se ha convertido en un foco principal, surgiendo de esta forma diversos sistemas
informticos. Los Sistemas de Transporte Inteligente (ITS), estn siendo un eficiente apoyo en
la disminucin de problemas de transportes urbanos e interurbanos, no solo mejorando la
movilidad, sino hacindola mucho ms sostenible. Estos pueden describirse como la unin
entre los avances en las tecnologas de informacin y las comunicaciones (TICs), las cuales
han revolucionado el mbito del transporte, permitiendo incluso realizar algunos servicios que
hasta ahora haban sido impracticables.
La base de los ITS est formada por la adquisicin de datos de diferentes dispositivos
(estaciones remotas, radares, detectores infrarrojos, anlisis de imgenes, etc.), los cuales son
procesados por diferentes computadores para la elaboracin de informacin, la cual una vez
integrada, se ofrece al usuario para ayudarlo en la toma de decisiones. Algunas aplicaciones
tpicas de los ITS son las cmaras de video para detectar accidentes, tableros de mensajes
dinmicos de informacin, detectores de vehculos para calcular tiempos de recorrido,
sistemas de pago electrnico, centros de gestin de trnsito, sistemas inteligentes de
semforos, sistemas de interaccin con el cliente, sistemas proactivos orientados al manejo de
colisiones, entre muchos otros.
Eliminado: , e

52
Sin embargo, por mucho que se instalen nuevos centros de gestin de trfico, se mejoren
las comunicaciones o se incremente la tecnologa utilizada por los diferentes tipos de
transporte, siempre queda, lo que en definitiva, puede mejorar o empeorar la situacin: el
factor humano.
5.2 Sistemas Flexibles de Transporte de Pasajeros
Cuando tenemos que elegir el tipo de transporte para cualquier tipo de viaje, por lo
general existen dos alternativas: o bien un transporte con un costo relativamente bajo, y con
horarios y rutas rgidas (tradicional transporte pblico local); o bien un transporte con un costo
mucho ms elevado, pero con una alta calidad y comodidad (autos privados y taxis). Pero
esencialmente, no hay diferencias de servicio entre estas dos alternativas. A pesar que este
mercado no es libre, es posible regular la movilidad local de este para apoyar y favorecer el
surgimiento y desarrollo de un sistema de transporte flexible, ofreciendo de esta forma un
nivel de calidad medio entre el transporte pblico tradicional y el taxi, el cual sera
competitivo para una amplia gama de demandas de movilidad [Picco, 2009].
La urbanizacin ha provocado adems un fuerte aumento en los trayectos, tanto de las
afueras de la ciudad, como tambin de las poblaciones locales. Esto se debe principalmente al
incremento del poder adquisitivo de cada una de las personas, como tambin a la necesidad de
rutas especiales que se adapten de mejor forma a sus requerimientos personales.
La economa actual, cada vez ms orientada al servicio, fomenta el que la mayora de las
personas tenga una amplia gama de posibilidades a la hora de escoger que transporte utilizar,
considerando no solo que la movilidad sea frecuente y ms extendida, sino que tambin de
mayor calidad. Muchos usuarios del transporte habitual se han visto afectados en gran medida,
debido a que su movilidad se ha reducido, porque no tienen acceso, costos razonables ni
servicios adecuados para ellos. Existen principalmente dos problemas que afectan la
utilizacin de los servicios de transporte pblico a las personas, uno es el insuficiente servicio
prestado, correspondiente a aspectos como la frecuencia, reas de servicio, etc., y el otro
problema es la existencia de vehculos y rutas inapropiadas, especialmente para personas con
enfermedades o discapacidades. Frente a todos estos problemas e inconvenientes, surgen los
denominados Sistemas Flexibles de Transporte, entre los cuales se encuentran los servicios de
Transporte de Respuesta a Demanda (DRT). El DRT es una forma de transporte pblico
avanzada, orientada al usuario y caracterizada por la realizacin de trayectos flexibles y la
programacin de vehculos operando en modo de trayectos compartido entre las paradas de
subida y bajada, de acuerdo a las necesidades que hayan especificado los pasajeros.
DRT forma parte de una estrategia sostenible de gestin de la movilidad destinada a
reas de baja densidad de poblacin o reas con perodos de baja demanda de
desplazamientos. Es un sistema eficiente y est orientado hacia el usuario del transporte
pblico, todo esto para hacer frente a las cambiantes necesidades de movilidad. Las rutas,
Eliminado:

53
tiempos de salida, los vehculos e incluso los operadores pueden ser regulados para ajustarse a
la demanda. El componente clave de DRTs, es un sistema automatizado por computador que
maneja el personal del centro de control, proporcionando rutas dinmicas (alternativas), y
programando los vehculos, junto con las operaciones de informacin y contabilidad
correspondientes.
Este tipo de transporte constituye un complemento a la actual red de transporte,
destinado principalmente a suplir las necesidades de transporte de personas con necesidades de
transporte especiales, como tambin suplir la demanda de transporte en pocas de baja
demanda, como la producida en das feriados, fines de semana o en las noches [Cubillos,
2005].
Para llevar a cabo la implementacin y manejo de este tipo de servicios, es fundamental
que los usuarios cuenten con instrumentos amigables y adems que la organizacin encargada
de los servicios sea capaz de manejar el conjunto de recursos de transporte que estn
involucrados. Para esto, es necesario que la arquitectura de los sistemas de respuesta a
demanda cuenten con la adecuada tecnologa de comunicaciones y herramientas tecnolgicas
[Cubillos, 2005].
5.3 Dial-a-Ride Problem
Los sistemas de transporte de respuesta a demanda, desde el punto de vista de la
investigacin de operaciones y de las matemticas, corresponden a un problema conocido
como Dial-a-Ride Problem (DARP). El DARP consiste en el diseo de rutas de vehculos y
horarios para usuarios, los cuales especifican solicitudes de transporte desde un punto de
origen (punto de recoleccin) a un punto de destino (punto de entrega). En la versin estndar,
el transporte es suministrado mediante una flota de vehculos idnticos basados en la misma
estacin.
El objetivo es planificar un conjunto de rutas de vehculos de costo mnimo con
capacidad de acomodar tantas solicitudes como les sea posible, considerando adems las
diversas restricciones de transporte que puedan existir. La capacidad, ventanas de tiempo,
precedencia, tiempo de viaje, entre otras, constituyen algunas restricciones que debe satisfacer
la solucin planteada de problema, mientras que restricciones como el uso compartido o
exclusivo del transporte o habilitacin de espacios para sillas de ruedas, constituyen
restricciones del tipo de servicio que se desea tener [Cordeau y Laporte, 2002].
Desde el punto de vista del modelamiento, el DARP generaliza un conjunto de
problemas de ruteo de vehculos, tales como el Pick-up and Delivery Vehicle Routing Problem
(PDVRP) y el Vehicle Routing Problem with Time Windows (VRPTW). Lo que diferencia el
DARP de estos problemas de ruteo, es el punto de vista humano, debido a que en el transporte
de pasajeros, la reduccin de las molestias del usuario debe ser equilibrada con la

54
minimizacin de costos de operacin. Adems, la capacidad del vehculo constituye una
restriccin en el DARP, no as en problemas de PDVRP, particularmente los relacionados con
la recepcin y entrega de cartas o paquetes pequeos [Cordeau y Laporte, 2002].
Los servicios del Dial-a-Ride pueden operar de un modo esttico o dinmico. En el
primer caso, todas las solicitudes de transporte se conocen de antemano, mientras que en el
segundo, estas solicitudes se obtienen en el transcurso del da y las rutas de los vehculos se
ajustan en tiempo real, satisfaciendo de esta forma la demanda generada.
La mayora de los estudios del DARP asumen una flota homognea de vehculos
basadas en una sola estacin. Si bien, en la mayora de los casos, esta hiptesis refleja la
realidad, es importante tener en cuenta que pueden existir otro tipo de situaciones en la
prctica, es decir, la existencia de varias estaciones, como tambin flotas heterogneas. En las
flotas heterogneas, pueden surgir situaciones como: algunos vehculos pueden estar
diseados solo para el transporte de sillas de ruedas, otros nicamente para el transporte de
pasajeros ambulatorios, y algunos diseados para ambos casos [Cordeau y Laporte, 2002].
La principal consideracin de algunos problemas, es el determinar el tamao y
composicin de la flota, la cual debe ser capaz de satisfacer todas las demandas, mientras que
en otros, es maximizar la cantidad de demanda satisfecha con una flota de tamao fijo. De lo
anterior, se pueden considerar dos problemas: el primero es minimizar los costos sujetos a la
satisfaccin total de la demanda; y el segundo es maximizar la satisfaccin de la demanda
sujeta a la disponibilidad de vehculos. En ambos casos se deben considerar las restricciones
dadas.
5.4 Arquitectura MADARP
MADARP (Multiagent Dial-a-Ride Problem), es una arquitectura destinada a la
planificacin y programacin de pedidos de transporte de pasajeros en un ambiente dinmico.
MADARP es parte de un modelo de capas que permite la implementacin de diferentes tipos
de sistemas de transporte de pasajeros. Esta arquitectura proporciona un sistema base
constituido por agentes, los cuales realizan la interfaz bsica, el planeamiento y los servicios
de soporte para manejar los diversos tipos de peticiones de transporte, utilizando una flota
heterognea de vehculos. Mediante la extensin e implementacin de la base de agentes
proveda por MADARP, se obtiene como resultado un sistema de transporte de pasajeros en
concreto [Cubillos, 2005].

55

Figura 5.1 Arquitectura MADARP [Cubillos, 2005]
La arquitectura MADARP se divide en cuatro capas, las cuales agrupan los agentes y las
estructuras de acuerdo a la funcionalidad que estos proporcionen, adems del nivel de
abstraccin que estos poseen. A continuacin se realizar una breve descripcin de cada una
de estas capas:
a) Capa de interfaz: Permite la conexin entre el mundo real y el sistema de transporte,
proporcionando agentes capaces de conectarse con los actores del sistema (operadores
de los vehculos y pasajeros del transporte).
b) Capa de planeamiento: Contiene agentes dedicados al procesamiento y planeamiento
de los viajes de cada uno de los vehculos de una manera distribuida.
c) Capa de servicio: Apoya a la capa de planeamiento con el fin de proporcionar diversas
funcionalidades complementarias, necesarias para entregar un servicio de transporte
integro.
d) Capa de ontologa: Proporciona un medio de integracin y cooperacin entre los
diferentes agentes y actores del sistema, permitiendo que estos puedan entenderse y
comunicarse de manera transparente y coherente.
Cabe destacar que el control se realiza de forma descentralizada, distribuyndose entre
las diferentes capas del sistema. De forma general, los agentes de interfaz proporcionan la
entrada y la seal monitoreada, para que luego los agentes de planeamiento puedan determinar
la planificacin de los vehculos involucrados. Los agentes de servicio apoyan todos estos
vietas

56
procedimientos, proveyendo la informacin requerida para el proceso de replanificacin
(debido a que es dinmico), y la ontologa ofrece las regulaciones necesarias para llevar a cabo
todo el control de interacciones.
Los tres actores principales involucrados en el sistema de transporte son los vehculos,
los clientes y la empresa de transporte, cada uno de los cuales se encuentra modelado en
trminos de agentes. En la metodologa MADARP, cada vehculo est representado mediante
un agente Vehculo y un agente Shedule, y del mismo modo, cada cliente est representado
mediante un agente Cliente y un agente Trip-request. En ambos casos, los agentes modelan
diferentes aspectos de la misma entidad real, por lo que se encuentran altamente acoplados,
considerndose como un solo actor. El tercer actor es la empresa de transporte, la cual est
construida sobre una serie de agentes, los cuales proveen diferentes servicios relacionados con
la planificacin y control del servicio de transporte de pasajeros proporcionado.
En el caso de los vehculos, los agentes que lo conforman proporcionan la
interoperabilidad entre el actor y el sistema de transporte al cual pertenece. El agente Vehculo
provee principalmente dos funcionalidades: la primera es entregar informacin relativa a
cambios en la planificacin original, como un nuevo cliente por transportar, una cancelacin
de transporte, cambios en las condiciones del trfico, etc. La segunda funcionalidad es
otorgarle al conductor un canal de comunicacin durante su jornada acerca de cualquier
contingencia que pueda presentarse. El agente Schedule est encargado de manejar la ruta del
vehculo y procesar cualquier nuevo pedido de transporte de un cliente.
En el caso de los clientes, los agentes que lo conforman proporcionan la interaccin del
actor con el servicio de transporte que este desea. El agente Cliente se encarga de capturar los
requerimientos de transporte, los cuales pueden ser relativos al tipo de transporte que se desee,
como tambin a las preferencias sobre situaciones de contingencia, por ejemplo, atrasos,
congestin vehicular, desviaciones, etc. Por otra parte, el agente Trip-request toma esos
requerimientos y preferencias para actuar a favor del cliente durante todo el proceso.
El rol del servicio de transporte se realiza principalmente por el agente Planner. Adems
existe un sistema entero de agentes que colaboran para dar soporte a las diferentes funciones
requeridas, por ejemplo, el concordar las peticiones con los vehculos, la contabilidad de
transacciones, el servicio de pago, entre otros.
En este proyecto se pretende incorporar un nuevo agente a la capa de interfaz, el cual
estar encargado de crear el entorno tridimensional del sistema de transporte, a partir de las
diversas interacciones que realicen los agentes entre s.

57

5.5 SIM-MADARP Baranlloni
En este apartado, se presentar el proyecto realizado en [Baranlloni, 2009], el cual
consiste en la realizacin de una interfaz 3D para un sistema de transporte de pasajeros basado
en la arquitectura MADARP.
Manager3D Schedule
Map
SchedGen
TripGen
Broker
EventClient
TripRequest
Planner
EventVehicle
Crear
Mapa
Gestionar
Mapa
<<include>>
Gestionar
Propuestas
Procesar
Solicitudes
Gestionar
Eventos
<<include>> <<c>>
Generar
Agentes
Schedule
Generar
Flota
Vehiculos
<<include>>
Obtener
Perfil
Cliente
Generar
Eventos
Trip-Request
Generar
Solicitud
de Viaje
<<include>>
<<include>>
Gestionar
Suscripciones
Generar
Matching
Vehiculos
<<include>>
Obtener
Eventos
Clientes
Mostrar
Eventos
Clientes
Generar
Eventos
Clientes
<<include>>
<<include>>
Gestionar
Itinerarios
Vehiculos
Procesar Eventos
Externos
Vehiculos
Procesar
Eventos
Vehiculos
Generar
Propuestas
<<include>>
Mostrar
Eventos
Vehiculos
<<include>>
<<c>>
<<c>>
<<c>> <<c>>
<<c>>
<<c>>
<<c>>
<<c>>
Negociar
Propuestas
Procesar
Eventos
Externos
Cliente
Procesar
Eventos
Cliente
Gestionar
Solicitudes
Cliente
<<c>>
<<c>>
<<c>>
Generar
Eventos
Vehiculos
Obtener
Eventos
Vehiculos
<<include>>
<<include>>
<<c>>
<<c>>
<<c>>
<<include>>
<<include>>
<<include>>
<<c>>
<<c>>
Generar
Mapa 3D
Gestionar
Motor 3D
<<include>>
Procesar
Visualizacion
Eventos
Gestionar
Datos
<<include>>
<<c>>
<<c>>
<<c>>
Monitor
<<c>>

Figura 5.2 Identificacin de agentes proyecto relacionado [Baranlloni, 2009]
En un comienzo, se analiz cada uno de los agentes que conformaban el sistema de
transporte realizado en [Donoso y Sandoval, 2009], a partir de este anlisis, se concluy que la
mejor forma de implementar la interfaz 3D, era creando un nuevo agente perteneciente a la

58
capa de interfaz de la arquitectura MADARP, debido principalmente a que las diversas
comunicaciones que eran necesarias para su funcionamiento pertenecan a capas con un nivel
de abstraccin superior. En este sentido, se considera principalmente los puntos extremos del
modelo, en donde se realizan las diferentes instrucciones que interactan con los vehculos, la
creacin de la flota inicial de transporte, y la obtencin del perfil del cliente para conocer los
usuarios que utilizan el servicio; siendo no relevante para el proyecto la lgica resolutiva del
sistema de transporte de pasajeros respecto a la toma de decisiones.
Los parmetros necesarios para el funcionamiento del sistema MADARP, se encuentran
en un archivo de texto, el cual ha sido modificado con el fin de indicar al sistema si se desea o
no utilizar la visualizacin 3D, en caso de ser as, se debe especificar la ruta de otro archivo, el
cual contiene la informacin sobre la distribucin de los diferentes nodos involucrados en la
creacin del mapa 3D.
El nuevo agente Manager3D del diagrama de identificacin de agentes (ver Figura 5.2),
es el encargado de todo lo relacionado con la creacin y administracin del entorno 3D, como
es la generacin del escenario, la actualizacin de los eventos, la creacin de los vehculos y
clientes, etc. La informacin requerida por el agente Manager3D, se obtiene a partir de la
incorporacin de nuevas funcionalidades a los agentes del sistema de transporte. Estas
funcionalidades consisten en la capacidad de transmisin de informacin respecto a los
eventos que estos realizan, principalmente lo que es la creacin de vehculos (SchedGen), la
creacin de clientes (TripGen), y la actualizacin de eventos en los vehculos (EventVehicle).
El ciclo de vida del motor grfico comienza con la inicializacin del sistema, en el cual
se obtiene la informacin de los parmetros entregados por el archivo de texto, para luego
empezar a cargar cada uno de los modelos necesarios con sus respectivas texturas. Una vez
terminado este proceso, se inicializa la luz y el cielo del entorno. La siguiente fase del ciclo de
vida es la implementacin del bucle principal, cada motor grfico posee un bucle en el cual se
realizan todas las operaciones que debe estar continuamente realizando, con la actualizacin
final de la pantalla; en este caso, los procedimientos implementados en este bucle consideran
la actualizacin del estado de cada uno de los vehculos del sistema, con el fin de calcular el
comportamiento que estos tendrn en la interfaz 3D. Finalmente el ciclo de vida termina
cuando se cierra la aplicacin.
Las funcionalidades otorgadas por la interfaz grfica son: mostrar detalles del bus,
mostrar detalles de clientes y cambiar la cmara. La primera y segunda de las funcionalidades,
tiene como objetivo informar al usuario sobre el estado actual en que se encuentran los
diferentes buses y clientes del sistema, mientras que el cambiar cmara, tiene como objetivo
otorgar diferentes puntos de vista al usuario respecto a la posicin que este se encuentra en el
mundo 3D, con el fin de que el sistema pueda ser observado desde distintos lugares.

59

Figura 5.3 Imagen del estado final de la interfaz proyecto relacionado [Baranlloni, 2009]
En la Figura 5.3 se puede observar la interfaz 3D desarrollada en el proyecto. La carga
de los diferentes modelos 3D se realiz acorde a los diversos requerimientos del sistema, en
donde las ubicaciones de estos se modifican de acuerdo a las localizaciones dispuestas por el u
usuario en el archivo de inicializacin de la interfaz.
Cabe mencionar que en este proyecto surgieron algunos problemas relacionados con la
carga de las texturas de los diferentes modelos 3D, pero su solucin se pospuso en post de
continuar con la programacin de la interfaz.

Figura 5.4 Modelos 3D proyecto relacionado [Baranlloni, 2009]
Los modelos 3D utilizados en el desarrollo de la interfaz fueron: el vehculo para el
transporte (ver Figura 5.4 (a)) y los paraderos en donde se realizan las diferentes solicitudes de
viajes por parte de los clientes (ver Figura 5.4 (b)).

60
Captulo 6: Desarrollo del Proyecto
6.1 Presentacin del Caso de Estudio
El problema que se aborda en este proyecto posee varios puntos. La motivacin
principal es el realizar una representacin grfica de componentes internos de un sistema, para
su posterior anlisis y comprensin. Si bien algunos elementos del sistema seleccionado no
sern representados en su exactitud, se buscar realizar una aproximacin lo ms cercana a su
funcionamiento. A continuacin se explican los diferentes puntos que componen el caso de
estudio de este proyecto.
6.1.1 Problemas Relacionados
Algunos de los problemas que se han identificado en el desarrollo del proyecto son:
Trabajo en paralelo: Si bien, el SMA est desarrollado para trabajar en diferentes hilos
de ejecucin, esto no quiere decir que la interfaz grfica tambin lo ser,
principalmente por la diferencia de paradigma utilizado en la implementacin del
software. El primer problema vendra a ser la representacin tarda de tareas que se
pueden estar realizando en el Sistema Multiagente hacia el motor grfico, al igual que
la ejecucin de comandos externos que no se vean rpidamente reflejados en el sistema
interno; mientras que el segundo problema, es que la realizacin de las actividades de
cada uno de los buses funcione de forma secuencial, sin que se note una fluidez en su
desplazamiento.
Seguimiento de rutas: Uno de los retos a la hora de desarrollar el software, es que cada
uno de los actores involucrados en el sistema tenga la capacidad de seguir
determinados caminos o rutas, por ejemplo, el recorrido de un bus comienza desde la
estacin y continua por cada una de las calles, detenindose en los diferentes puntos en
donde se puedan subir o bajar clientes, y se termina al volver a su punto de origen.
Incompatibilidad grfica: Debido a que cada uno de los modelos 3D pertenecientes al
sistema se disean en un software de modelado independiente del motor grfico, es
probable que surjan inconvenientes al momento de querer importar al mundo 3D
dichos modelos. Algunos de estos problemas pueden ser por ejemplo: errores de
formato, deformaciones de la malla, errores en las texturas, entre otros.
Errores en el sistema seleccionado: A pesar de estar centrado principalmente en el
desarrollo del visualizador 3D, esto no impide que puedan existir algunos errores en el
Sistema de Transporte seleccionado, retrasando el objetivo final del proyecto.
Eliminado:

61
Escasa fluidez de movimientos: Otro punto a trabajar, es el funcionamiento final del
software, esto est determinado principalmente por el hardware utilizado al momento
de levantar la interfaz grfica, como tambin por el nivel de complejidad
implementado en el programa. En este sentido, se buscar un equilibrio entre la
complejidad del sistema, y la capacidad del hardware.
6.1.2 Tecnologas Utilizadas
En este proyecto se aplicarn diversas tecnologas y conceptos expuestos en captulos
anteriores, con el fin de crear diversos prototipos incrementales.
Ya que el sistema de transporte de pasajeros se ha implementado utilizando la
plataforma de desarrollo de agentes JADE, se ha optado por la utilizacin del motor grfico
jMonkeyEngine, debido principalmente a que ambos software trabajan con el lenguaje de
programacin Java, evitando de esta forma posibles errores de compatibilidad al momento de
querer intercambiar informacin.
Para el desarrollo de cada uno de los elementos que conformarn el entorno 3D, se ha
optado por la utilizacin del software de modelado Blender, ya que como se mencion
anteriormente, es gratuito y otorga una gran serie de herramientas, siendo adems el software
de modelado recomendado por la comunidad de programadores y diseadores de
jMonkeyEngine.
La parte del diseo del proyecto relacionada con el Sistema Multiagente se realizar
mediante la utilizacin de la metodologa de desarrollo de agentes PASSI, mientras que el
diseo del funcionamiento del motor grfico se realizar mediante la utilizacin de diagramas
UML, este cambio de metodologa se debe principalmente a la diferencia de paradigma
involucrada en el desarrollo de ambas partes.
6.1.3 Desarrollo del Caso de Estudio
De forma general, el proyecto estar compuesto por un escenario tridimensional, en el
cual se ubicarn los vehculos, clientes y los diferentes puntos de recoleccin, a partir de los
cuales se podrn subir y bajar los clientes del servicio de transporte segn las solicitudes de
viajes que estos hayan realizado. Adems, se incorporar la estacin de buses, utilizada
principalmente para la generacin de los buses, su salida y retorno.
Los parmetros de entrada se obtendrn a partir de un archivo de texto, el cual se utiliza
principalmente para la inicializacin del sistema de transporte con el cual se est trabajando,
en este caso, adems se le aadir la opcin de utilizar o no la interfaz grfica, de ser as, se
generar el mundo virtual bsico, al cual se le irn aadiendo ms elementos a medida que
este vaya obteniendo informacin.
Eliminado: s

62
Todos los elementos pertenecientes al mundo sern representados con un modelo 3D en
particular, entre los que se encuentran: vehculos, clientes, paraderos, edificios, estacin, entre
otros. El entorno en que se ubicar todo el sistema ser detallado una vez que se cumpla el
objetivo principal del proyecto, debido a que no es indispensable para su funcionamiento.
Adems, tanto la ciudad como la localizacin de los paraderos y la estacin de los buses se
establecern de forma fija, principalmente para modelar el mundo 3D de forma mucho ms
detallada, centrndose en el objetivo principal del proyecto.
Respecto al Sistema Multiagente ya implementado, se le incorporar un nuevo agente, el
cual estar encargado de tomar la informacin necesaria de los otros agentes involucrados,
como tambin de realizar diversos comportamientos en el sistema. A los agentes ya
implementados en el sistema de transporte, se les aadir la caracterstica de poder informar su
estado y comportamiento actual al agente de interfaz, permitiendo de esta forma captar esta
informacin y envirsela al motor grfico para que este pueda procesarla y transformarla a
representaciones visuales del sistema.
La interaccin con las diferentes entidades 3D del entorno se realizar mediante el
despliegue de un panel de informacin en la entidad seleccionada, el cual otorgar un conjunto
de acciones posibles respecto a dicha entidad. Estas acciones inducen a comportamientos que
generan nuevos eventos en el sistema de transporte, tanto por parte de los clientes como de los
vehculos. Algunos de estos eventos pueden ser por ejemplo: la cancelacin de una solicitud
de viaje, el abandono del punto de recoleccin de un cliente, el atraso de un bus en su tiempo
de salida o su detencin mientras se movilizaba por algn imperfecto.
Otros eventos que tambin sern incorporados, pero no tienen una relacin directa con el
Sistema Multiagente son: la capacidad de modificar la cmara, por ejemplo, asignrsela a un
determinado vehculo para seguir su camino, o a un determinado cliente; la posibilidad de
cambiar de modo dentro de la interfaz, siendo posible modificar algunos atributos de
elementos como la ciudad en la cual se basa el sistema; etc.
6.2 Diseo del Sistema
6.2.1 Anlisis del Sistema Existente
A partir del anlisis del proyecto presentado en apartado 5.5 se puede obtener una
visualizacin previa del diseo del simulador del sistema de transporte relacionado con la
captura de la informacin.
Como se mencion anteriormente, el nuevo agente denominado Manager3D se
encargar de obtener informacin de los otros agentes del sistema, envindosela
posteriormente al motor grfico para su posterior procesamiento y representacin, este nuevo
agente adems podr inducir comportamientos en los eventos de los vehculos y de los clientes

63
del sistema de transporte. En la Figura 6.1 se presenta el diagrama de Descripcin del
Dominio realizado en [Donoso y Sandoval, 2009].
Crear
Mapa
Gestionar
Mapa
<<include>>
Gestionar
Propuestas
Procesar
Solicitudes
Gestionar
Eventos
<<include>>
<<c>>
Generar
Agentes
Schedule
Generar
Flota
Vehiculos
<<include>>
Obtener
Perfil
Cliente
Generar
Eventos
Trip-Request
Generar
Solicitud
de Viaje
<<include>>
<<include>>
Gestionar
Suscripciones
Generar
Matching
Vehiculos
<<include>>
Obtener
Eventos
Clientes
Mostrar
Eventos
Clientes
Generar
Eventos
Clientes
<<include>>
<<include>>
Gestionar
Itinerarios
Vehiculos
Procesar
Eventos
Externos
Vehiculos
Procesar
Eventos
Vehiculos
Generar
Propuestas
<<include>>
Mostrar
Eventos
Vehiculos
<<include>>
<<c>>
<<c>>
<<c>>
<<c>>
<<c>>
<<c>>
<<c>>
<<c>>
Negociar
Propuestas
Procesar
Eventos
Externos
Cliente
Procesar
Eventos
Cliente
Gestionar
Solicitudes
Cliente
<<c>>
<<c>>
<<c>>
Generar
Eventos
Vehiculos
Obtener
Eventos
Vehiculos
<<include>>
<<include>>
<<c>>
<<c>>
<<c>>
<<include>>
<<include>>
<<include>>
<<c>>
<<c>>
Monitor
<<c>>

Figura 6.1 Descripcin del dominio proyecto relacionado [Donoso y Sandoval, 2009]
A partir del diagrama anterior, se consideran principalmente las funcionalidades que
interactan directamente con el motor grfico, obviando en gran parte de las que estn ligadas
con la lgica resolutiva del problema. A continuacin se presentan los casos de uso necesarios
para la creacin de la interfaz 3D:
Obtener Eventos Vehiculos: Genera los eventos del lado del vehculo, para que luego
estos sean solicitados por Generar Eventos Vehiculos en base a la probabilidad de
ocurrencia de cada uno. Debido a que se permitir una interaccin externa con el motor
grfico hacia el Sistema Multiagente, tambin se podrn crear nuevos eventos en los
vehculos a partir de la interaccin con los diferentes vehculos 3D.

64
Obtener Eventos Clientes: Genera los eventos simulados traducidos en eventualidades
que afectan uno o varios de sus viajes ya programados, tales como, retrasos en su
llegada al punto donde debe ser recogido por el vehculo, o bien, cancelaciones. Al
igual que en Obtener Eventos Vehiculos, tambin se pueden crear nuevos eventos en
un cliente, mediante la interaccin con su objeto 3D respectivo.
Generar Eventos Vehiculos: Gestiona los eventos provenientes del lado del conductor
simulado, por ejemplo, presencia o ausencia de un pasajero en el punto de recogida o
retrasos en la llegada del vehculo debido a desvos, congestiones o fallas. Tanto si se
ha especificado una captura de eventos mediante una simulacin aleatoria o una
captura de eventos a partir de lo que ha inducido directamente el usuario, esta
funcionalidad es la encargada de gestionar dichos eventos e interactuar posteriormente
con el agente de interfaz grfica.
Generar Eventos Cliente: Gestiona los eventos que se van produciendo mientras dura
la ejecucin del sistema. Al igual que en Generar Eventos Vehiculos, esta
funcionalidad es la encargada de gestionar los eventos generados, ya sean simulados, o
creados a partir de la interfaz.
Obtener Perfil Cliente: Obtiene las caractersticas del cliente que desea un determinado
servicio de transporte ofrecido por la empresa. En este caso, sirve para mantener
informado al usuario de la interfaz sobre las caractersticas de los diferentes clientes
3D ubicados en el mundo.
Generar Flota Vehiculos: Genera los vehculos que interactan con el sistema de
transporte, los cuales posteriormente deben ser creados en la interfaz 3D.
Las otras funcionalidades en gran parte se encargan principalmente de generar las
diversas rutas para los vehculos, como tambin de permitir re-planificaciones en caso de que
surjan imprevistos en la realizacin del servicio. Otra de las funcionalidades internas que
realiza el sistema, es la gestin y creacin del mapa, la cual permite ver la cobertura, tiempos y
costos asociados a las diversas rutas soportadas por la empresa de transporte, permitiendo de
esta forma determinar si es posible la realizacin de un servicio de transporte solicitado por un
cliente.
6.2.2 Modelo Requerimientos del Sistema
En este primer modelo de la metodologa de desarrollo de agentes PASSI, se ha obviado
del diagrama de descripcin del dominio, debido a su explicacin realizada en la seccin
anterior, procediendo directamente a la especificacin de las nuevas funcionalidades e
interacciones del agente Manager3D.
6.2.2.1 Identificacin de Agentes

65
En la Figura 6.2 se puede observar el mismo diagrama de identificacin de agentes
presentado en el artculo 5.5, el cual se ha modificado con el fin de adecuarse a los nuevos
requerimientos de la interfaz. Este bsicamente realiza las mismas funcionalidades, pero ahora
incorporando el inducir eventos en los agentes EventVehicle y EventClient, adems de la
comunicacin entre Generar Eventos Clientes y Procesar Visualizacion Eventos.

Manager3D
Schedule
Map
SchedGen
TripGen
Broker
EventClient
TripRequest
Planner
EventVehicle
Crear
Mapa
Gestionar
Mapa
<<include>>
Gestionar
Propuestas
Procesar
Solicitudes
Gestionar
Eventos
<<include>> <<c>>
Generar
Agentes
Schedule
Generar
Flota
Vehiculos
<<include>>
Obtener
Perfil
Cliente
Generar
Eventos
Trip-Request
Generar
Solicitud
de Viaje
<<include>>
<<include>>
Gestionar
Suscripciones
Generar
Matching
Vehiculos
<<include>>
Obtener
Eventos
Clientes
Mostrar
Eventos
Clientes
Generar
Eventos
Clientes
<<include>>
<<include>>
Gestionar
Itinerarios
Vehiculos
Procesar Eventos
Externos
Vehiculos
Procesar
Eventos
Vehiculos
Generar
Propuestas
<<include>>
Mostrar
Eventos
Vehiculos
<<include>>
<<c>>
<<c>>
<<c>> <<c>>
<<c>>
<<c>>
<<c>>
<<c>>
Negociar
Propuestas
Procesar
Eventos
Externos
Cliente
Procesar
Eventos
Cliente
Gestionar
Solicitudes
Cliente
<<c>>
<<c>>
<<c>>
Generar
Eventos
Vehiculos
Obtener
Eventos
Vehiculos
<<include>>
<<include>>
<<c>>
<<c>>
<<c>>
<<include>>
<<include>>
<<include>>
<<c>>
<<c>>
Generar
Mapa 3D
Gestionar
Motor 3D
<<include>>
Procesar
Visualizacion
Eventos
Gestionar
Datos
<<include>>
<<c>>
<<c>>
<<c>>
Monitor
<<c>>
Inducir
Eventos
Internos
<<c>>
<<c>>
<<c>>
<<include>>
<<include>>

Figura 6.2 Diagrama de identificacin de agentes [Elab. Propia]
Con formato: Normal,
Interlineado: sencillo

66
A partir del diagrama de descripcin del dominio presentado en el artculo 7.1, se han
agrupado las diversas funcionalidades que otorga el sistema en paquetes, los cuales
representan los diferentes actores involucrados. En el nuevo agente Manager3D incorporado
al actual sistema de transporte, se pueden observar cinco casos de uso, los cuales se detallan a
continuacin:
Inducir Eventos Internos: Se encarga de crear nuevos eventos en los agentes
EventVehicle y EventClient, los cuales no se simulan de forma aleatoria, sino que son
especificados directamente por el usuario de la interfaz.
Gestionar Datos: Se encarga de recibir y almacenar la informacin necesaria del
sistema para su posterior procesamiento.
Procesar Visualizacion Eventos: Captura las diferentes solicitudes de transporte y
eventos producidos por el caso de uso Generar Eventos Clientes, como tambin de
capturar los diversos eventos obtenidos de los vehculos por el caso del caso de uso
Generar Eventos Vehiculos.
Gestionar Motor 3D: Realiza la interaccin entre el motor grfico y el Sistema
Multiagente, ya sea enviando informacin del sistema de transporte hacia la interfaz, o
bien recibiendo comportamientos desde la interfaz y envindoselos sistema de
transporte.
Generar Mapa 3D: Se ejecuta al inicializar el agente Manager3D, capturando la
informacin necesaria para la inicializacin del motor grfico y la posterior creacin
del entorno.
6.2.2.2 Identificacin de Roles
En esta fase se analizan los diferentes escenarios y roles que se encuentran involucrados
en la interaccin entre los diferentes agentes del sistema.
Los roles definidos para el agente Manager3D han sido el de GestorEntorno y el de
GeneradorEventos, el primero de estos se encarga principalmente de la captura de la
informacin proveniente de los dems agentes, como tambin de la interaccin con el motor
grfico; mientras que el segundo se encarga de la captura y envo de los eventos seleccionados
por el cliente de la interfaz, hacia los agentes correspondientes en el Sistema Multiagente
(vehculos o clientes).
Debido al tipo de interaccin que posee el agente TripGen con el agente Manager3D,
solo se le ha establecido el rol GeneradorDeSolicitudes, el cual como su nombre lo indica, se
encarga de generar las solicitudes de viaje por parte de los clientes del sistema, las cuales
posteriormente son informadas al agente Manager3D. De la misma forma, el agente SchedGen
Eliminado: En la Figura 6.2 se
puede observar el mismo diagrama
de identificacin de agentes
presentado en el artculo 5.5, el
cual se ha modificado con el fin de
adecuarse a los nuevos
requerimientos de la interfaz. Este
bsicamente realiza las mismas
funcionalidades, pero ahora
incorporando el inducir eventos en
los agentes EventVehicle y
EventClient, adems de la
comunicacin entre Generar
Eventos Clientes y Procesar
Visualizacion Eventos.

67
posee el rol GeneradorDeVehiculos, encargado de generar los diferentes vehculos para suplir
la demanda de solicitudes de viaje e informar al agente Manager3D de su creacin.
Finalmente, los agentes EventClient y EventVehicle poseen dos roles, los cuales son
GeneradorDeEventos y ComunicadorDeEventos, el primero se encarga de crear los eventos en
el sistema, mientras que el segundo rol se encarga de ir informando de los diferentes eventos
ya creados al agente Manager3D.
InicializadorSimulacion
: MainAgent
GestorEntorno :
Manager3D
GeneradorDeSolicitudes :
TripGen
: Usuario Interfaz
GeneradorDeVehiculos
: ShedGen
1 : iniciarSimulacion()
2 : leerDatosMapa()
3 : enviarDatosMapa()
4 : inicializarMotorGrafico()
5 : generarVehiculos()
6 : informarFlotaVehiculos()
7 : generarSolicitud()
8 : enviarDatosCliente()
9 : procesarDatos()

Figura 6.3 Escenario de captura de informacin inicial [Elab. Propia]
La Figura 6.3 muestra el escenario inicial del sistema, en el cual, a partir de la
inicializacin del simulador por parte del agente MainAgent, se obtiene la informacin
correspondiente del grafo a utilizar por el sistema, la que posteriormente se enva al agente
Manager3D para la inicializacin y generacin del entorno 3D en el motor grfico. Tanto la
creacin de la flota inicial de vehculos como la generacin de una nueva solicitud de viaje se
informan al agente Manager3D, para que este pueda procesar los datos y actualizar el entorno.
El escenario presentado en la Figura 6.4 muestra el caso en que se genera un nuevo
evento en un vehculo a partir de la interfaz 3D. Luego de haber seleccionado el evento
correspondiente a un vehculo determinado en la interfaz, el agente Manager3D se encarga de

68
inducir ese evento en el agente EventVehicle, el cual posteriormente crea el evento y se lo
enva al agente Schedule para que lo procese, una vez realizado dicho procesamiento, se
informa el resultado al agente EventVehicle, el cual se encarga finalmente de entregar los
datos necesarios al agente Manager3D.
ComunicadorDeEventos
: EventVehicle
GestorEntorno :
Manager3D
GeneradorDeEventos
: EventVehicle
ProcesadorDeEventos
: Schedule
GeneradorEventos
: Manager3D
1 : inducirNuevoEventoVehiculo()
2 : crearEventoVehiculo()
3 : procesarAccion()
4 : resultadoAccion()
5 : informarResultadosEventoVehiculo()
6 : procesarEventos()

Figura 6.4 Escenario de generacin de evento en vehculo [Elab. Propia]
Al igual que en el escenario anterior, en la Figura 6.5 se puede observar la generacin de
un evento hacia el cliente del servicio de transporte, en donde las funcionalidades de los dos
roles pertenecientes al agente Manger3D interactan de forma similar con los roles
GeneradorDeEventos y ComunicadorDeEventos del agente EventClient.
Si bien, tanto los eventos el vehculo como del cliente pueden ser generados de forma
aleatoria, solo se ha presentado el escenario en que se obtienen a partir de la interfaz, ya que
en el caso contrario, simplemente bastara con crear internamente de forma aleatoria el evento
por parte del agente EventVehicle o el agente EventClient, saltndose los pasos realizados por
el rol GeneradorEventos del agente Manager3D, pero manteniendo todo el flujo de acciones
que se llevan a cabo posteriormente.

69
ComunicadorDeEventos
: EventClient
GestorEntorno :
Manager3D
GeneradorDeEventos
: EventClient
GestionadorDeSolicitudes
: TripRequest
GeneradorEventos
: Manager3D
1 : inducirNuevoEventoCliente()
2 : crearEventoCliente()
3 : procesarAccion()
4 : resultadoAccion()
5 : informarResultadosEventoCliente()
6 : procesarEventos()

Figura 6.5 Escenario de generacin de evento en cliente [Elab. Propia]
6.2.2.3 Especificacin de Tareas
En esta fase se utilizan diagramas de actividad para describir como los agentes pueden
hacer uso de sus tareas para cumplir con sus objetivos.
Cada diagrama est compuesto por dos calles, la calle derecha representa las tareas del
agente el cual se est describiendo, mientras que la calle izquierda describe las tareas de los
otros agentes. Las transiciones realizadas en una misma calle representan el flujo de control
entre tareas diferentes, mientras que las transiciones realizadas entre las dos calles representan
las comunicaciones realizadas entre los agentes. La parte del sistema perteneciente a la calle
izquierda no se realiza de forma exhaustiva, ya que el enfoque se centra en el agente descrito
en la calle derecha, solo las comunicaciones entrantes y salientes desde/hacia el agente
descrito se muestra en la calle izquierda.
La Figura 6.6 describe las tareas del agente Manager3D con los dems agentes,
comenzando en un principio por el envo de la informacin de los vehculos para la
inicializacin del motor. Las diferentes solicitudes de viaje de los clientes son gestionadas para
luego ser utilizadas cuando se requieran. La creacin de los eventos en los vehculos y
clientes, se realizan en los agentes correspondientes para posteriormente ser procesados por el
agente Manager3D, siendo finalmente gestionados y enviados al motor grfico.

70
Other agents Manager3D Other agents
inducirNuevoEventoVehiculo
inicializarMotorGrafico
procesarVisualizacionEventos
capturarEventoVehiculoInterfaz
EventVehicle.generarNuevoEvento
<<EventVehicle task>>
MainAgent.crearManager3D
<<MainAgent task>>
gestionarMotor3D
MainAgent.enviarDatosVehiculos
<<MainAgent task>>
EventVehicle.capturarEvento
EventVehicle.surgirEventoSimulado
TripGen.generarSolicitudViaje
<<TripGen task>>
gestionarDatos
capturarEventoClienteInterfaz
inducirNuevoEventoCliente
EventClient.surgirEventoSimulado
<<EventClient task>>
EventClient.capturarEvento
EventClient.generarNuevoEvento

Figura 6.6 Especificacin de tareas [Elab. Propia]
6.2.3 Modelo de Sociedad de Agentes
En este modelo se busca representar las interacciones sociales de los diferentes agentes
del sistema, como tambin las dependencias que los componen. Se han extendido las
caractersticas de los diagramas realizados en el diseo del simulador del sistema de transporte
inicial en donde se posee una relacin directa con el agente Manager3D, por lo que se
presentarn nicamente los agentes e interacciones que se encuentren involucrados con dicho
agente. Cabe mencionar que se ha obviado de la descripcin del dominio, ya que los diversos
conceptos, predicados y acciones corresponden al sistema de transporte como tal (ver Figura
A.1). De manera similar, tambin se ha obviado de la descripcin de protocolos, debido a que
la transferencia de mensajes entre los agentes son nicamente informativos, sin tener la
necesidad de utilizar o crear un protocolo complejo.

71
6.2.3.1 Descripcin de Ontologa de Comunicacin
En este diagrama se especifican los diferentes tipos de comunicacin realizados entre los
agentes que componen el sistema mediante la utilizacin de diagramas de clases. Las
comunicaciones son definidas por la relacin entre dos agentes, y se detallan en su clase los
atributos de dicha relacin, los cuales son: la ontologa, el lenguaje de comunicacin y el
protocolo de interaccin.
Manager3D
<<Agent>>
EventClient
<<Agent>>
TripGen
<<Agent>>
SchedGen
<<Agent>>
EventVehicle
<<Agent>>
SchedGen-Manager3D
<<communication>>
+Ontology: Informar
+Language: FIPA ACL
+Protocol: none
TripGen-Manager3D
<<communication>>
+Ontology: Informar
+Language: FIPA ACL
+Protocol: none
EventClient-Manager3D
<<communication>>
+Ontology: Informar
+Language: FIPA ACL
+Protocol: none
EventVehicle-Manager3D
<<communication>>
+Ontology: Informar
+Language: FIPA ACL
+Protocol: none
Manager3D-EventClient
<<communication>>
+Ontology: Inducir Evento
+Language: FIPA ACL
+Protocol: none
Manager3D-EventVehicle
<<communication>>
+Ontology: Inducir Evento
+Language: FIPA ACL
+Protocol: none

Figura 6.7 Descripcin de ontologa de comunicacin [Elab. Propia]
Como se mencion anteriormente, debido al carcter informativo de la comunicacin
que existe entre los diferentes agentes involucrados en el sistema, no se ha necesitado de un
protocolo de interaccin ya definido para el envo de los mensajes. En la Figura 6.7 se pueden
observar las comunicaciones realizadas entre los agentes, los cuales utilizan FIPA ACL para
definir la estructura de los mensajes y ontologas de comunicacin bsicas para la
especificacin de conceptos comunes en el dominio.


72
6.2.3.2 Descripcin de Roles
Manager3D
<<Agent>>
GestorEntorno : Manager3D
-gestorEntorno()
-inicializarMotorGrafico()
-recibirActualizacionMundo3D()
EventClient
<<Agent>>
EventVehicle
<<Agent>>
TripGen
<<Agent>>
SchedGen
<<Agent>>
GeneradorEventos : Manager3D
-generadorEventos()
+inducirEventoVehiculo()
+inducirEventoCliente()
ComunicadorDeEventos : EventClient
-comunicarEventos()
-comunicadorDeEventos()
-recibirActualizacion()
GeneradorDeEventos : EventClient
-generadorDeEventos()
-crearEventos()
GeneradorDeEventos : EventVehicle
-generadorDeEventos()
-simuladorViaje()
ComunicadorDeEventos : EventVehicle
-comunicarEventos()
-comunicadorDeEventos()
-actualizarEstadoCliente()
GeneradorDeSolicitudes : TripGen
-generadorDeSolicitudes()
-informarDatosCliente3D()
GeneradorDeVehiculos : ShedGen
-generadorDeVehiculos()
-informarCreacionVehiculos3D()
informar evento cliente informar evento vehculo
inducir evento vehculo
inducir evento cliente
informar datos cliente
informar creacin vehculo
[Cambio Rol] [Cambio Rol]
[Cambio Rol]

Figura 6.8 Descripcin de roles [Elab. Propia]

73
El diagrama de descripcin de roles corresponde a un diagrama de clases, en donde los
agentes se encuentran agrupados en paquetes y sus roles en clases, la relacin entre dichos
roles pueden representar cambios de rol, dependencias por un servicio, disponibilidad de un
recurso o comunicaciones. En esta fase se busca describir principalmente el ciclo de vida de
los agentes respecto a los roles que cada uno de estos puede efectuar en la ejecucin del
sistema.
En la Figura 6.8 se pueden observar las dependencias que poseen los diferentes roles del
sistema con el agente Manager3D para poder llevar a cabo su objetivo, el cual vendra a ser la
gestin de la informacin para su envo al motor grfico y la generacin de eventos hacia los
clientes y vehculos. Los nombres de las acciones se han simplificado, por lo que no
representan realmente los mtodos necesarios a implementar por los agentes, esto se ver en la
siguiente fase de la metodologa PASSI.
6.2.4 Modelo de Implementacin de Agentes
En este tercer modelo de PASSI, se busca representar la solucin de la arquitectura del
en trminos de clases y mtodos, en donde se define por una parte la estructura del Sistema
Multiagente y por otra la estructura de los agentes individuales.
En este proyecto se ha obviado de la descripcin del comportamiento de los agentes,
debido a que no es relevante para el posterior desarrollo e implementacin del sistema.
6.2.4.1 Definicin de la Estructura Multiagente
En esta fase se hacen uso de diagramas de clases para representar la estructura de la
solucin del Sistema Multiagente. En la Figura 6.9 se puede observar una aproximacin ms
cercana a la implementacin de la interfaz y las relaciones que poseen los agentes entre s.
Como puede observarse en el diagrama, el nico atributo que almacena el agente
Manager3D que posee directa relacin entre el Sistema Multiagente y el motor grfico es la
variable app, la cual almacena el motor grfico como tal en su completitud. A partir de esta
variable se inicializa el sistema grfico y las propiedades de la ventana, como tambin se
realiza todo el proceso de envo y captura de informacin del entorno mediante la llamada de
sus diversos mtodos pblicos.
La no utilizacin de una cantidad de variables tan extensa se debe a que el agente
Manager3D acta principalmente como un intermediario entre el simulador de transporte y la
interfaz grfica, este realiza el procesamiento cuando es necesario y llama a los mtodos de la
interfaz 3D, sin tener que almacenar informacin de lo realizado, como puede ser el listado de
vehculos o clientes, las diferentes solicitudes de viajes, el grafo donde se almacena la
informacin de las rutas, entre otros.

74
Manager3D
<<Agent>>
-Interfaz3D app
-int width
-int height
-boolean isVSync
-boolean isFullscreen
-boolean isPausedInLostFocus
-boolean isDisplayStats
-boolean isDisplayFps
-int antialiasingValue
-inducirEvento()
EventClient
<<Agent>>
+TripRequestAgent myTripRequest = null
-int type_event
-int users_server = 0
-Ramdom rr = new Random(1)
-long tripGenSeed = 0
-informarActualizacion3D()
-Create_events_Behaviour()
-Create_events_Behaviour_3D()
TripGen
<<Agent>>
-int i = 0
-BufferedWriter outLogError
-String usersFile = ""
-String directory = null
-int MODE = 0
-double c1 = 0
-double c2 = 0
-double c3 = 0
-double c4 = 0
-TimeSpan default A = new TimeSpan(0, 0, 0, 0)
-double default_B = (double) 1.0
-TimeSpan default_WS = new TimeSpan(0, 0, 0, 0)
-TimeSpan default_TServUp = new TimeSpan(0, 0, 0, 0)
-TimeSpan default_TServDown = new TimeSpan(0, 0, 0, 0)
-boolean bool_soon = false
+Vector USERS
-long seed = 0
-Generate_trip_agents_Behaviour()
SchedGen
<<Agent>>
-BufferedWriter outLogError
-String vehicles_file = "no_name\n"
-String directory = null
-Vector FLEET
-int MODE = 0
-double c5 = 0
-double c6 = 0
-int size
-Generate_schedule_agents_Behaviour()
EventVehicle
<<Agent>>
+ScheduleAgent mySchedule = null
-String bus_status = ""
-int index = 0
-long dist
-long realdist
-long now
-actualEvent = null
-nextEvent = null
-Random rr = new Random(1)
-long tripGenSeed = 0
-Trip_simulator_Behaviour()

Figura 6.9 Definicin de la estructura Sistema Multiagente [Elab. Propia]
Los mtodos del agente Manager3D son:
inicializarMotorGrafico: Encargado de generar una instancia del motor grfico, enviar
los datos necesarios para su inicializacin y posteriormente ejecutarlo.
recibirActualizacionMundo3D: Se encarga de enviar hacia el motor grfico los
diferentes cambios realizados en el Sistema Multiagente (cancelacin de un viaje por
parte del cliente, problemas en la va, ausencia de un cliente en su paradero de
recogida, entre otros).

75
inducir Evento: Captura el evento del vehculo o del cliente en la interfaz y lo enva al
agente EventVehicle o al agente EventClient correspondientemente. La reaccin luego
de generar el evento es capturada por el mtodo explicado anteriormente (denominado
como recibirActualizacionMundo3D).
6.2.4.2 Definicin de la Estructura de los Agentes Individuales
Al igual que en el apartado 6.2.4.1, se hace uso de diagramas de clases para representar
la estructura de la solucin, pero en este caso se realiza con cada uno de los agentes del
sistema de forma individual.
A partir de las diferentes clases definidas por la plataforma de desarrollo de agentes
JADE, se han hecho uso de CyclicBehaviour y OneShotBehaviour para especificar el
comportamiento en los agentes del sistema, el cual depende en cada caso si debe realizarse una
sola vez, o de forma indefinida.
A continuacin se explican los diferentes comportamientos definidos para los agentes:
Agente Manager3D (Figura 6.10):
recibirActualizacinMundo3D: Definido como un CyclicBehaviour, en el cual
se podrn ir recibiendo constantemente las diversas actualizaciones de estados
y eventos producidos en el sistema.
Agente TripGen (Figura 6.11):
Generate_trip_agents_Behaviour: A medida que se vayan obteniendo los
diversos clientes del sistema, se ira informando al agente Manager3D mediante
un el mtodo informarActualizacion3D.
Agente SchedGen (Figura 6.12):
Generate_schedule_agents_Behaviour: Hace uso de un OneShotBehaviour para
informar de la creacin de los diversos vehculos, en este caso se realiza una
sola vez, ya que se enva la lista completa con los datos necesarios dentro de
ese comportamiento.
Agente EventVehicle (Figura 6.13):
Create_events_Behaviour: Genera los eventos de manera aleatoria.
Create_events_Behaviour_3D: Genera los eventos a partir de lo que ha enviado
el motor grfico.

76
Trip_simulator_Behaviour: Obtiene la informacin de las solicitudes que
generan los clientes hacia los vehculos del simulador.
Agente EventClient (Figura 6.14):
Create_events_Behaviour: Genera los eventos de manera aleatoria.
Create_events_Behaviour_3D: Genera los eventos a partir de lo que ha enviado
el motor grfico.
Manager3D
<<Agent>>
-Interfaz3D app
-int width
-int height
-boolean isVSync
-boolean isFullscreen
-boolean isPausedInLostFocus
-boolean isDisplayStats
-boolean isDisplayFps
-int antialiasingValue
-inducirEvento()
JADEAgent
(from JADE)
<<Agent>>
CyclicBehaviour
(from JADE )
<<Agent>>
SimpleBehaviour
(from JADE)
<<Agent>>
Behaviour
(from JADE)
<<Agent>>
recibirActualizacionMundo3D
<<Task>>

Figura 6.10 Definicin de la estructura agente Manager3D [Elab. Propia]

77
TripGen
<<Agent>>
+int i = 0
+BufferedWriter outLogError
+String usersFile = ""
+String directory = null
+int MODE = 0
+double c1 = 0
+double c2 = 0
+double c3 = 0
+double c4 = 0
+TimeSpan default A = new TimeSpan(0, 0, 0, 0)
+double default_B = (double) 1.0
+TimeSpan default_WS = new TimeSpan(0, 0, 0, 0)
+TimeSpan default_TServUp = new TimeSpan(0, 0, 0, 0)
+TimeSpan default_TServDown = new TimeSpan(0, 0, 0, 0)
+boolean bool_soon = false
+Vector USERS
+long seed = 0
-Generate_trip_agents_Behaviour()
JADEAgent
(from JADE)
<<Agent>>
Behaviour
(from JADE)
<<Agent>>
Generate_trip_agents_Behaviour()
<<Task>>
TickerBehaviour
(from JADE)
<<Agent>>

Figura 6.11 Definicin de la estructura agente TripGen [Elab. Propia]
SchedGen
<<Agent>>
+BufferedWriter outLogError
+String vehicles_file = "no_name\n"
+String directory = null
+Vector FLEET
+int MODE = 0
+double c5 = 0
+double c6 = 0
+int size
-Generate_schedule_agents_Behaviour()
JADEAgent
(from JADE)
<<Agent>>
OneShotBehaviour
(from JADE)
<<Agent>>
SimpleBehaviour
(from JADE)
<<Agent>>
Behaviour
(from JADE)
<<Agent>>
Generate_schedule_agents_Behaviour()
<<Task>>

Figura 6.12 Definicin de la estructura agente SchedGen [Elab. Propia]

78
EventVehicle
<<Agent>>
+ScheduleAgent mySchedule = null
+String bus_status = ""
+int index = 0
+long dist
+long realdist
+long now
+actualEvent = null
+nextEvent = null
+Random rr = new Random(1)
+long tripGenSeed = 0
-Trip_simulator_Behaviour()
JADEAgent
(from JADE)
<<Agent>>
OneShotBehaviour
(from JADE)
<<Agent>>
SimpleBehaviour
(from JADE)
<<Agent>>
Behaviour
(from JADE)
<<Agent>>
TickerBehaviour
(from JADE)
<<Agent>>
Create_events_Behaviour_3D
<<Task>>
Create_events_Behaviour
<<Task>>
Trip_simulator_Behaviour
<<Task>>

Figura 6.13 Definicin de la estructura agente EventVehicle [Elab. Propia]
EventClient
<<Agent>>
+TripRequestAgent myTripRequest = null
+int type_event
+int users_server = 0
+Ramdom rr = new Random(1)
+long tripGenSeed = 0
JADEAgent
(from JADE)
<<Agent>>
SimpleBehaviour
(from JADE)
<<Agent>>
Behaviour
(from JADE)
<<Agent>>
Create_events_Behaviour_3D
<<Task>>
OneShotBehaviour
(from JADE)
<<Agent>>
TickerBehaviour
(from JADE)
<<Agent>>
Create_events_Behaviour
<<Task>>

Figura 6.14 Definicin de la estructura agente EventClient [Elab. Propia]
6.2.4.3 Datos de Entrada

79
El simulador de transporte actualmente utiliza un archivo denominado Adartw.ini, el
cual bsicamente contiene toda la informacin necesaria para la inicializacin del sistema, en
donde algunos de los campos sirven por ejemplo para especificar el modo en que se ejecutar
el simulador, definir la ruta del archivo contenedor del grafo, especificar si se utilizar
compresin de la matriz, establecer el nmero de ejecuciones que se realizarn, indicar el
directorio, entre otros.
En la Tabla 6.1 se puede observar los diversos datos utilizados por el simulador, adems
de la incorporacin de la lnea INTERFACE_3D, la cual indica si se utilizar o no la
interfaz 3D al momento de ejecutar el simulador de transporte, siendo sus posibles estados 1 o
0 respectivamente.
Como se mencion anteriormente, se har uso de un grafo definido de manera esttica,
por lo que a diferencia del proyecto realizado en [Baranlloni, 2009], se ha descartado la
utilizacin de un archivo que almacene las coordenadas reales a utilizar por los diferentes
nodos/paraderos en el mundo 3D, siendo remplazado por una ciudad creada de forma
predefinida, al igual que el grafo de inicializacin del sistema.
Tabla 6.1 Archivo de inicializacin de datos [Donoso y Sandoval, 2009]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
MODE = 0
3D_INTERFACE = 1
A = 0 0 3 0
B = 1.10
WS = 0 0 2 0
DIRECTORY = doc
C1 = 1.0
C2 = 0.0
C3 = 1.0
C4 = 0.0
C5 = 1.0
C6 = 1.0
SOON = true
GRAPH_CHECK = true
COMPRESSED_MATRIX = false
RUNS = 1
GRAPH_FILE = graph.txt
VEHICLES_FILE_M0 = buses_m0.txt
USERSFILE_M0 = users_m0
USERSSTART_M0 = 1
USERSFILECOUNT_M0 = 2
VEHICLES_FILE_M1 = buses_m1.txt
USERSFILE_M1 = users_m1
USERSSTART_M1 = 1
USERSFILECOUNT_M1 = 2

6.2.5 Diseo Motor Grfico

80
En este apartado se realizar la fase de diseo correspondiente al funcionamiento del
motor grfico, en donde se identificarn por una parte las caractersticas otorgadas al usuario
de la interfaz, y por otra las funcionalidades realizadas de forma interna por el motor,
considerando un diseo no exhaustivo del mismo, lo que quiere decir que solo se evaluarn los
puntos fundamentales para la posterior implementacin del Sistema Multiagente y la interfaz
3D. Los puntos mencionados anteriormente corresponden al diagrama casos de uso, para
describir las funcionalidades del sistema; el diagrama de actividad, a partir del cual se
identificar el proceso que debe seguir la interfaz; y finalmente el diagrama de clases, en
donde se identificarn todas las estructuras de datos necesarias.
6.2.5.1 Diagrama Casos de Uso
En este diagrama se presentan las diferentes funcionalidades que otorga el motor
grfico al usuario de la interfaz (ver Figura 6.15), estas funcionalidades de forma general
consisten en:
Modificar Cmara: Permite modificar la velocidad y localizacin de la cmara con la
cual se observa el entorno. Respecto a su localizacin, esta puede ser fijada sobre
alguna otra entidad (cliente o vehculo), otorgando una visin en tercera persona, o ser
localizada en modo espectador, permitiendo modificar de forma manual su ngulo y
posicin.
Modificar Vehculo: Permite obtener informacin sobre un determinado vehculo,
inducir un nuevo evento, o fijarle la cmara para realizarle un seguimiento en tercera
persona.
Modificar Cliente: Al igual que en el modificar vehculo, esta funcionalidad permite
obtener informacin sobre un determinado cliente, inducir un nuevo evento, o fijarle la
cmara en tercera persona.

81
System
Usuario
Interfaz
Desplegar
Sub-Men
Cliente
Desplegar
Sub-Men
Vehculo
Desplegar
Sub-Men
Nodo
Mostrar
Datos
Cliente
Mostrar
Detalle
Vehculo
<<extend>>
<<extend>>
Inducir
Evento
Cliente
<<extend>>
Inducir
Evento
Vehculo
<<extend>>
Fijar
Cmara
Vehculo
<<extend>>
Fijar
Cmara
Cliente
<<extend>>
Mostrar
Datos Nodo
<<extend>>
Seleccionar
Nodo Parada
Seleccionar
Vehculo
Seleccionar
Cliente
<<include>>
<<include>>
<<include>>

Figura 6.15 Caso de uso usuario de interfaz [Elab. Propia]
6.2.5.2 Diagrama de Actividad

82
Interface3D Vehiculo3D Cliente3D Interface3D
Setear Captura
Pantalla por Mouse
Crear Skybox Cielo
Crear Iluminacin
y Sombras
Cargar Modelo
Escenario Ciudad
Iniciar Interfaz
Cargar Modelo
Vehculo 3D
Cargar Modelo
Cliente 3D
Inicializar Datos
Vehculo
lista vehiculos incompleta
Iniciar Msica
Inicializar Datos
Cliente
Generar Path Finding
nueva solicitud viaje
Inicio Bucle Motor
fin generacin vehculos
Actualizar Estado
Vehculo
cambio estado/evento vehculo
Actualizar Pantalla
continua aplicacin
fin aplicacin
ningn cambio vehculo
sin solicitudes viaje
Cambiar
Caractersticas
Cmara
cambio estado/evento cliente
Actualizar Estado
Cliente
ningn cambio cliente
modificar cmara no modificar cmara

Figura 6.16 Diagrama de actividad [Elab. Propia]

83
En la Figura 6.16 se puede observar todo el ciclo de vida de la interfaz, en donde
comienza inicializando las diferentes variables y entidades 3D del entorno, para luego
continuar ejecutando el bucle que contiene todo el proceso de captura y envo de informacin
al Sistema Multiagente, con la posterior actualizacin de la pantalla.
El motor grfico, luego de haber sido inicializado por el agente Manager3D, configura
un conjunto de elementos, entre los cuales se encuentran:
El foco de la interfaz por mouse, en donde la rotacin de la cmara se realiza
nicamente seleccionando la pantalla, permitiendo de esta forma liberar el control de
recursos que produce la aplicacin.
El skybox, el cual consiste en el medio para la creacin del cielo en la ciudad, esto se
realiza utilizando un cubo texturizado en su interior, el cual cubre todo el entorno,
dando la sensacin al usuario de estar mirando al cielo.
La creacin de las diferentes luces (tanto ambientales como luces direccionales para el
sol) y la activacin de las sombras en las diferentes geometras.
La generacin de la ciudad 3D, la cual almacena los diferentes edificios, veredas,
paraderos y calles, adems de la estacin para los vehculos.
La creacin del Path Finding, para que los diferentes vehculos puedan transitar por
las calles. Esto se realiza mediante la utilizacin de un conjunto de vectores rectilneos
y curvos definidos por jMonkeyEngine para el desplazamiento de geometras.
La inicializacin y activacin de la msica ambiental.
Finalmente la carga de los diferentes vehculos 3D, proceso que se realiza de forma
indefinida hasta que ya se hayan cargado todos los vehculos del sistema establecidos
en la lista enviada por el agente Manager3D.
Una vez realizado todo este proceso de inicializacin del entorno, comienza el bucle del
motor, el cual es fundamental para la mayor parte de las aplicaciones grficas. Este bucle se
encarga de realizar todos los procesos que tienen que estar continuamente calculndose, como
el movimiento de geometras, la captura de informacin, control de colisiones, aplicacin de
fsicas, entre muchas otras.
En este caso, el bucle se encarga en un primer momento de verificar si han surgido
cambios de estado o nuevos eventos en los vehculos, de ser as, se deben actualizar los datos
de dicho vehculo y realizar su posterior cambio de movimiento. Luego se verifica si han
surgido nuevas solicitudes de viaje por parte de los clientes, se genera el modelo 3D del
cliente y se inicializan sus datos. Nuevamente se realiza la captura de cambios de estado o
nuevos eventos, pero por parte de los clientes, con su posterior actualizacin como respuesta.

84
Si se desea modificar la cmara, entonces se realizan los cambios en sus caractersticas.
Finalmente se muestran por pantalla todos los cambios producidos anteriormente, y se evala
si se seguir ejecutando la aplicacin.
6.2.5.3 Diagrama de Clases
En la Figura 6.17 se pueden observar las cuatro clases definidas para este proyecto y las
relaciones que estas poseen. Estas clases son:
Interfaz3D: Esta clase corresponde al motor grfico, encargado de procesar toda la
informacin obtenida y actualizarla por pantalla.
Vehiculo3D: Clase que contiene toda la informacin y acciones posibles que puede
realizar cada uno de los vehculos en el mundo 3D.
Cliente3D: Clase que contiene la informacin relativa a los clientes y los servicios de
transporte que estos realizan.
Paradero3D: Clase que almacena el objeto tridimensional de los nodos.

85
Interfaz3D
-AudioNode musica
-Vehiculos3D vehiculos
-int cant_vehiculos
-Cliente3D clientes
-int cant_clientes_nodo
-int cant_clientes_nodo_dejada
-cont_ult_cliente
-Paradero3D paraderos
-MotionPath grafo_rutas
-Spatial edificios_1, edificios_2
-Node ciudad
-CameraNode cam_node
-boolean camara_asignada
-String ultimo_nombre, ultimo_tipo_nombre
-PssmShadowRenderer pssmRenderer
-Manager3D m3d
-boolean debug_path
-Nifty nifty
-Element popup
-int cont_msgbox
-String aux_tipo, aux_id, nombre_vehiculo, nombre_cliente
-int aux_i
+Interfaz3D(Manager3D m3d)
+simpleInitApp()
-inicializarInterfaz()
-inicializarEstructuras()
-inicializarEntornoGeneral()
-inicializarPathFinding()
-inicializarMusica()
-inicializarDispositivosEntrada()
-createMyPopupMenu()
-showMenu()
-ActionListener()
-AnalogListener()
+incorporarVehiculo(String id_vehiculo, String indice)
+incorporarCliente(String id_cliente, int nodo_o, int nodo_d)
-obtenerPosicionCliente(int nodo, int indice_nodo, int paradero)
-obtenerPosicionParadero(int nodo)
+modificarRutaVehiculo(String nombre_bus, int id_bus, ...)
+cancenarViajeCliente(String nombre)
+errorCancelarVehiculo()
+errorCancelarCliente()
-obtenerNodoEntidad(String nombre)
+bind(Nifty nifty, Screen screen)
+onStartScreen()
+ondEndScreen()
+quit()
+destroy()
+simpleUpdate()
Vehiculo3D
-SimpleApplication app
+String id, nombre
+Node nodoSpatial
+Spatial modelo
-int estacion_bus
+int ruta_ult
-boolean bloqueado
+Vector viajes
+int indice_viaje
+Vector clientes
-boolean cancelar_viaje
-ParticleEmitter humo_colapso
+String estado
+Vehiculo3D(String nombre, ...)
+initialize(...)
-crearHumoColapso()
+obtenerRuta()
+calcularSiguienteRuta()
+incorporarRuta(int nuevo_nodo, ...)
+cancelarViaje()
+update(float tpf)
Cliente3D
+String id, nombre
+Spatial modelo
+Node nodoSpatial
+int nodo_o, nodo_d, paradero, recoger
-boolean subir_vehiculo, bajar_vehiculo
-boolean cancelar_viaje
-Vehiculo3D vehiculo
+Cliente3D(String id, String nombre, ...)
+initialize(...)
+subirVehiculo(Vehiculo3D vehiculo)
+bajarVehiculo(Vehiculo3D vehiculo)
+cancelarViaje()
+update(float tpf)
SimpleApplication
1
1..*
1
1..*
AbstractAppState
Paradero3D
-int id
-Spatial modelo
-Node nodoSpatial
+Paradero3D(int id, Spatial modelo, ...)
+initialize(...)
+update(float tpf)
AbstractAppState
1..*
1
AbstractAppState

Figura 6.17 Diagrama de clases interfaz [Elab. Propia]
6.2.6 Diseo de la Ciudad
En la Figura 6.18 se presenta el grafo no direccionado utilizado para la creacin de la
ciudad, en este diagrama se pueden identificar 13 nodos, los cuales corresponden a los
diferentes pares de paraderos en donde los clientes podrn realizar las diversas solicitudes de
viaje, el enlace entre estos nodos representa las calles por donde transitarn los vehculos, las
cuales se han establecido en ambos sentidos.

86
Nodo/paradero
de la ciudad
Calle por donde
transitan los vehculos

Figura 6.18 Grafo no dirigido de paraderos [Elab. Propia]
A partir del grafo anterior, se ha creado el diagrama de la Figura 6.19, el cual
corresponde a una aproximacin ms cercana de la implementacin que se realizar de la
ciudad. En este diagrama se pueden identificar dos paraderos por nodo, esto se debe a que los
vehculos para poder tomar o dejar clientes, solo pueden transitar por la va que corresponda al
sentido en que se dirige dicho vehculo.
La estacin de los buses se ha creado en la parte norte de la ciudad, en donde en un
comienzo se ubicarn todos los buses definidos en el archivo de entrada, una vez estos buses
hayan realizado su recorrido, se devolvern al punto de origen.
La creacin de los clientes se realizar nicamente en las cercanas de los paraderos en
donde estos realizarn sus solicitudes de viaje, y tendrn que esperar all hasta que llegue el
vehculo que los recoger, o hasta que se genere un evento que cancele su solicitud, realizando
la animacin correspondiente. Adems, una vez asignado un determinado paradero al cliente,
se realizar de forma aleatoria su asignacin a un lado de la calle o al otro, y de la misma
forma con el nodo destino.

87

Figura 6.19 Diagrama ciudad a simular [Elab. Propia]
Cada uno de estos vehculos se desplazar de forma continua por los diferentes caminos
de la ciudad en relacin al nodo destino hacia el cual debe ir, por lo que se obviar el sistema
de colisin que podra generarse cuando dos vehculos se interpongan entre s, ya que esto
implicara una modificacin en el simulador, lo que impedira el cumplimiento de los
objetivos propuestos para este proyecto.
En el diagrama anterior se puede observar que las rutas de los vehculos, al desarrollarse
en ambos sentidos, implica el tener que reorganizar la ruta prxima antes de empezar a mover
el bus, ya que este nunca debe transitar por la va contraria a su sentido.

Captulo 7: Pruebas de Software
La realizacin de pruebas es fundamental para verificar que se estn realizando de forma
correcta las funcionalidades que debe cumplir la aplicacin, como tambin validar que el
Con formato: Justificado,
Sangra: Primera lnea: 0,95
cm
Eliminado:
Salto de pgina

88
proceso de implementacin se est llevando a cabo lo mejor posible. Existen muchos tipos de
pruebas, por ejemplo: pruebas estructurales o de caja blanca, funcionales o de caja negra, de
rendimiento, de seguridad, de usabilidad, de mantenibilidad, entre otros. Debido a la
imposibilidad de probar el sistema de manera exhaustiva, se considerarn ciertos criterios para
elegir buenos casos de prueba.
7.1 Planificacin de las Pruebas
El plan de pruebas de forma general tiene como objetivo determinar el esquema de
actividades de prueba, as como tambin el enfoque, los elementos a probar, sus caractersticas
y los criterios a utilizar.
Debido al tipo de aplicacin con la cual se est trabajando, los enfoques seleccionados
para la realizacin de las pruebas sern principalmente de caja negra y de caja blanca, en
donde se evaluarn las entradas y salidas correspondientes del sistema, considerando adems
el funcionamiento interno del mismo. Se han escogido estos tipos de prueba, debido a que es
necesario ver la forma en que interacta la interfaz con el medio que lo rodea (el cual en
muchos casos depende de los cambios externos y la informacin enviada desde otras fuentes),
adems de las tareas que se realizan al momento de realizar una funcionalidad determinada.
Un tercer tipo de prueba a realizar es de rendimiento, pero orientado a la cantidad de
actualizaciones de pantalla que puede realizar la interfaz por cada segundo, buscando un
equilibrio entre la cantidad de elementos que se muestren por pantalla (cantidad de tringulos,
calidad de texturas, calidad de las sombras, entre otros) y la capacidad del hardware con el
cual se estn realizando dichas pruebas. Cabe mencionar, que la realizacin de estos tipos de
pruebas se ejecutar en conjunto, dependiendo principalmente de que es lo que se desee
evaluar.
Los elementos que se probarn en un comienzo corresponden a datos pertenecientes a la
fase de inicializacin de la aplicacin, como la activacin de la sincronizacin vertical, la
correcta resolucin de pantalla, la generacin de un skybox, la carga de texturas, etc. Luego se
realizarn pruebas relacionadas con la inicializacin, pero ejecutadas nicamente por el motor
grfico. Posteriormente se realizarn pruebas de interconexin con el Sistema Multiagente, en
donde se evaluar que se est llevando a cabo de forma correcta la captura y creacin de los
diferentes datos/eventos por parte del agente Manager3D, como tambin la correcta
implementacin de la informacin obtenida en el motor grfico. Las pruebas de rendimiento
mencionadas anteriormente se ejecutarn en conjunto con las dems pruebas.
7.2 Diseo de las Pruebas
A continuacin se definir como se llevarn a cabo las diversas pruebas planificadas
para posteriormente obtener resultados esperados. El diseo relativo a las pruebas de caja

89
negra consiste principalmente en la evaluacin de un conjunto de escenarios con determinados
puntos de entrada y salida, el diseo de las pruebas de caja blanca se centra en las funciones
internas de un mdulo, y el diseo del rendimiento de la aplicacin consiste en la modificacin
directa en la calidad tanto de geometras como de texturas y sombras.
El proceso de prueba comienza con la modificacin de las diversas propiedades que
posee la ventana y la forma en que luego estas son reproducidas en la interfaz. En un primer
instante se realizarn modificaciones en la activacin/desactivacin del VSync, cambios en la
resolucin de la pantalla y el aumento o disminucin de la calidad del antialiasing. Los datos
esperados para estas modificaciones se presentan en las tablas siguientes:
Tabla 7.1 Prueba activacin/desactivacin VSync [Elab. Propia]
Nombre Prueba Activacin/desactivacin sincronizacin vertical.
Descripcin La activacin o desactivacin de la sincronizacin vertical implica la
modificacin directa de la cantidad de frames por segundo (fps) implementada
en un motor grfico. En el caso de estar activada, los fps generados por el
hardware grfico se reducen a los fps que pueden ser renderizados realmente
por la pantalla, los cuales por lo general se encuentran alrededor de los 60. El
encontrarse desactivado no limita la cantidad de fps renderizados, pero si da
lugar a la aparicin de ciertos errores grficos, como la desaparicin de
geometras, desfase de la pantalla, lneas intermitentes horizontales, entre otros.
Entradas Activacin o desactivacin del filtro.
Salidas Los resultados de la cantidad de fps y la aparicin o no de errores grficos.
Tabla 7.2 Prueba cambios en resolucin de la pantalla [Elab. Propia]
Nombre Prueba Cambios en la resolucin de la pantalla.
Descripcin Los cambios en la resolucin de la pantalla deben tener como consecuencia una
modificacin directa de la altura y anchura de la ventana al momento en que
esta es creada.
Entradas La altura y la anchura de la ventana.
Salidas Generacin de la ventana.
Tabla 7.3 Prueba aumento/disminucin calidad antialiasing [Elab. Propia]

90

Nombre Prueba Aumento/disminucin calidad filtro antialiasing.
Descripcin El aumento o disminucin de la calidad en el filtro antialiasing permite
especificar la tcnica que utilizar el motor grfico para eliminar el dentado en
los bordes de las imgenes. Es muy importante corroborar que este filtro no
juega un papel fundamental en el rendimiento final de la aplicacin, de lo
contrario, es mejor no hacer uso de l.
Entradas El nmero que especifica la calidad del filtro.
Salidas Los resultados de la cantidad de fps y la calidad del efecto de suavizado en las
superficies.
Una vez evaluados los puntos anteriores, se procede a realizar las pruebas sobre la
inicializacin de los diferentes modelos 3D, la generacin de luces y sombras, activacin de la
msica, funcionamiento correcto del Path Finding y la implementacin del skybox. Los datos
esperados son:
Tabla 7.4 Prueba iniciacin y carga de modelos 3D [Elab. Propia]
Nombre Prueba Iniciacin y carga de los modelos 3D.
Descripcin La iniciacin de los modelos 3D involucra la generacin de las entidades con
sus caractersticas generadas de forma correcta (no haya sido escalado en uno o
ms ejes, o se encuentre en una posicin errnea), el Mapping de la textura
realizada de forma exacta (la textura creada se aplique correctamente en la
geometra) y posea todos los polgonos que se hayan especificado.
Entradas La textura y el objeto que contiene toda la informacin de la geometra.
Salidas La visibilidad del modelo 3D con la carga de su respectiva textura.
Tabla 7.5 Prueba creacin de luces y sombras [Elab. Propia]
Nombre Prueba Creacin de luces y sombras.
Descripcin La creacin de luces debe afectar a todas las geometras de la escena sin
excepcin, independiente si esta es ambiental o direccional. La captura y
generacin de sombras debe ser activada por una parte en el motor grfico y por
otra en cada una de las geometras que pueda ser capaz de interactuar con esta.
Hasta el momento no se evaluar la calidad final de la sombra generada.
Entradas El tipo de luz, la direccin y el color que irradia, adems de la sombra que se
desea crear. En este caso son dos luces, las cuales se especificarn de forma
separada.
Salidas Los cambios del brillo en los diferentes objetos y la proyeccin de su sombra.
Tabla 7.6 Prueba creacin de la msica ambiental [Elab. Propia]

91

Nombre Prueba Creacin de la msica ambiental.
Descripcin La msica se iniciar de forma automtica al comenzar la aplicacin, se debe
comprobar que esta se ejecuta de forma indefinida y con un volumen moderado.
Hasta el momento solo se posee un archivo de msica, pero es suficiente para la
realizacin de las pruebas correspondientes.
Entradas El archivo que almacena la msica.
Salidas Si este archivo se reproduce de forma correcta en el motor.
Tabla 7.7 Prueba aplicacin del Path Finding [Elab. Propia]
Nombre Prueba Aplicacin del Path Finding.
Descripcin Respecto al Path Finding, se debe probar que sea aplicado de manera exacta a la
ciudad creada y que los diferentes vehculos sean capaces de seguirlo en la
direccin correspondiente al sentido de la calle.
Entradas Los diferentes vectores, sus sentidos y posiciones sobre la ciudad.
Salidas Si las geometras pueden recorrer dichos vectores, y si lo realizan de manera
fluida.
Tabla 7.8 Prueba creacin del skybox [Elab. Propia]
Nombre Prueba Creacin del skybox.
Descripcin Se utilizar la tcnica del skybox para la generacin del cielo que rodea la
ciudad, el cual independiente del tamao de las geometras que se encuentren
en su interior, se podr observar de igual manera.
Entradas El objeto que almacena la geometra (caja) con las 6 imgenes interiores del
cielo.
Salidas La existencia de errores en las conexiones que se producen entre las diferentes
caras de la caja, especialmente si las imgenes han sido aplicadas a dichas caras
en el ngulo correcto.
Las pruebas relacionadas con la interconexin entre el motor grfico y el Sistema
Multiagente van destinadas nicamente al envo o captura de la informacin, y la recepcin
correcta de los resultados en las diferentes geometras 3D involucradas (en especial los
vehculos y los clientes).
Adems de este tipo de pruebas, tambin se evaluarn las que tienen que ver con la
interaccin del sistema de forma general, es decir, todas las acciones que no se realicen de
forma automtica o simulada, por ejemplo la asignacin de la cmara a un determinado cliente
del servicio.
A continuacin se explican los casos de prueba realizados para esta ltima etapa del
diseo de pruebas:


92
Tabla 7.9 Prueba modificacin de la cmara [Elab. Propia]
Nombre Prueba Modificacin de la cmara.
Descripcin Como se mencion anteriormente, la cmara puede ser asignada en modo
espectador o fijada en una entidad, por lo que se debe poder probar su correcto
funcionamiento.
Entradas La accin a realizar sobre la cmara, ya sea cambindole de modo, rotndola,
movindola o fijndola.
Salidas Si la accin se ve reflejada de manera correcta, ubicando la cmara en un
ngulo y posicin cmodos para el usuario.
Tabla 7.10 Prueba captura de evento [Elab. Propia]
Nombre Prueba Captura de evento.
Descripcin En esta prueba se busca corroborar que la captura de eventos se realice de
forma correcta en el motor grfico, con los parmetros necesarios y en el
momento adecuado. Estos eventos pueden luego verse reflejados en los clientes
o en los vehculos.
Entradas El evento obtenido del Sistema Multiagente.
Salidas La accin realizada sobre la entidad especificada en el evento, esperando que
esta se haya realizado de forma correcta.
Tabla 7.11 Prueba generacin de evento [Elab. Propia]
Nombre Prueba Generacin de evento.
Descripcin Al momento de crear un evento en el motor, se debe comprobar que se hayan
especificado todos los datos necesarios para ser posteriormente inducidos de la
mejor manera al Sistema Multiagente.
Entradas El evento obtenido de la interfaz.
Salidas El resultado de la accin generado en el Sistema Multiagente, el que adems
debe ser enviado al motor grfico para presentar el resultado al usuario de la
interfaz (la realizacin de la accin en caso exitoso, o la aparicin de un
mensaje de error en caso contrario).

7.3 Datos de Prueba
Una vez definidos los escenarios de prueba a realizar, se deben especificar los datos de
entrada que el sistema y el motor grfico utilizarn. Especficamente se utilizarn 13
paraderos, 15 buses, y 50 clientes. En la Tabla 7.12 se muestra la matriz simtrica de
distancias entre los diferentes paraderos de la ciudad.

93

Tabla 7.12 Matriz de distancias [Elab. Propia]
1 2 3 4 5 6 7 8 9 10 11 12 13
1 40 40 60
2 40 60 60
3 40 40 70
4 60 40 50
5 60 40 20
6 60 20 30 60
7 90 50
8 70 50 50
9 50 30 60 80
10 30 50 50 70
11 60 50 50 40
12 50 60 50 60
13 80 70 40 60
A partir de la matriz anterior, se genera el archivo grafo.txt (ver Tabla 7.13), el cual
contiene la informacin de las distancias entre los nodos y el costo asociado a dichas
distancias. En este caso, solo se ha realizado el archivo para un escenario de prueba.

94
Tabla 7.13 Archivo de datos grafo [Elab. Propia]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

43
44
1 2 40 293
1 3 40 826
1 4 60 927
2 1 40 293
2 5 60 614
2 6 60 362
3 1 40 826
3 4 40 352
3 8 70 726
4 1 60 927
4 3 40 352
4 5 50 936
5 2 60 614
5 4 40 936
5 6 20 773
6 2 60 362
6 5 20 773
6 7 30 248

13 11 40 245
13 12 60 827

El formato del archivo contenedor del grafo en cada columna posee la siguiente
informacin [Donoso y Sandoval, 2009]:
nodo_o nodo_d d_tiempo d_costo
Dnde:
nodo_o: Nodo origen.
nodo_d: Nodo destino.
d_tiempo: Distancia en tiempo.
d_costo: Distancia en costo.
Los datos de los buses tambin se han especificado en un archivo, el cual se llama
buses.txt (ver Tabla 7.14).

95
Tabla 7.14 Archivo de datos buses [Elab. Propia]
1
2
3
4
5
6
7
8
9
10

15
$bus_1 10 1 1
$bus_2 10 1 1
$bus_3 10 1 1
$bus_4 10 1 1
$bus_5 10 1 1
$bus_6 10 1 1
$bus_7 10 1 1
$bus_8 10 1 1
$bus_9 10 1 1
$bus_10 10 1 1

$bus_15 10 1 1
El formato del archivo contenedor de los vehculos en cada columna posee la siguiente
id_v cap nodo_o nodo_d
Dnde:
id_v: Identificador del vehculo.
cap: Capacidad mxima de pasajeros.
nodo_o: Nodo depsito de origen.
nodo_d: Nodo depsito de destino.
Finalmente se utilizar el archivo clientes.txt (ver Tabla 7.15) para obtener la
simulacin de peticiones de viaje de un conjunto de clientes, los cuales poseen caractersticas
diferentes.

96
Tabla 7.15 Archivo de datos clientes [Elab. Propia]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

50
U U1 1 1 6 7:42:51 1
U U2 1 2 1 7:49:47 1
U U3 1 10 13 7:25:20 1
U U4 1 5 7 7:36:49 1
U U5 1 7 8 7:32:52 1
U U6 1 11 7 7:40:03 1
U U7 1 2 12 7:52:45 1
U U8 1 12 3 7:58:48 1
U U9 1 5 4 7:35:38 1
U U10 1 4 12 7:49:58 1
U U11 1 3 8 7:55:04 1
U U12 1 7 2 7:25:44 1
U U13 1 9 2 7:40:13 1
U U14 1 2 8 7:03:35 1
U U15 1 11 6 7:44:58 1
U U16 1 6 2 7:14:18 1
U U17 1 8 13 7:20:59 1
U U18 1 2 5 7:39:56 1
U U19 1 10 3 7:13:22 1
U U20 1 6 3 7:59:56 1
U U21 1 2 12 7:11:36 1
U U22 1 12 7 7:38:05 1
U U23 1 2 9 7:47:50 1
U U24 1 8 5 7:59:34 1
U U25 1 2 6 7:15:55 1
U U26 1 3 2 7:53:37 1
U U27 1 2 11 7:33:51 1
U U28 1 8 5 7:00:50 1
U U29 1 11 8 7:38:51 1
U U30 1 1 5 7:04:24 1

U U50 1 5 10 7:28:32 1
El formato del archivo contenedor de los clientes en cada columna posee la siguiente
id_c nom_c num_p nodo_o nodo_d hora op_hora
Dnde:
id_c: Identificador general del cliente.
nom_c: Nombre del cliente.
num_p: Nmero de pasajeros (acompaantes).
nodo_o: Nodo origen de la peticin.
nodo_d: Nodo destino de la peticin.

97
hora: Hora deseada de recogida o llegada.
op_hora: Opcin de la hora del cliente.

98

Captulo 8: Implementacin
En este captulo se realizar un anlisis en base al cumplimiento de los diferentes
objetivos del proyecto, evaluando en una primera instancia la creacin e integracin de las
diferentes geometras 3D en el entorno grfico, luego se continuar con el anlisis sobre la
interfaz de usuario que posee el simulador de transporte, posteriormente se presentarn
algunas mejoras relacionadas con la forma de visualizar el entorno grfico, y finalmente se
explicar el mtodo de solucin utilizado para implementar el sistema de rutas de los
vehculos en el entorno.
8.1 Conexin entre el SMA y el Motor Grfico
Para realizar la conexin entre el Sistema Multiagente y el motor grfico 3D se ha
realizado el flujo de acciones que se puede observar en la Figura 8.1, en donde cada uno de los
eventos que se generan en el simulador de manera automtica, se procesan y se envan al
agente Manager3D mediante un mensaje ACL, luego a partir de la instancia del motor grfico
que se posee en dicho agente, se realiza una llamada a sus mtodos pblicos para poder
informar los cambios que se han producido en el sistema, el cual finalmente procesa dicha
informacin dentro del entorno grfico y la representa por pantalla.
Generacin de
Eventos SMA
Captura de
Eventos SMA
Recepcin de
Eventos Agente
Manager3D
Recepcin de Eventos
Motor Grfico
Mediante sus Mtodos
Generacin de
Eventos Motor
Grfico
Recepcin de Eventos
Agente Manager3D
Mediante sus Mtodos

Figura 8.1 Conexin entre SMA y el motor grfico [Elab. Propia]

99
Por otro lado, se encuentra la captura de eventos por parte del motor grfico, en donde se
procesa dicha informacin en el mismo motor y se enva al agente Manager3D mediante los
mtodos pblicos de captura que este posee (por lo que puede verse el proceso inverso de
enva y captura de informacin descrito anteriormente). Luego de que el agente toma esa
informacin, se genera el mensaje ACL con el receptor correspondiente (un vehculo o un
cliente) y se le enva, siendo el resultado de esta accin capturada por el simulador y enviada
al agente Manager3D nuevamente, repitindose de esta forma el primer flujo de acciones para
representar en la interfaz 3D dichos eventos.
8.2 Desarrollo e Integracin de Modelos 3D
Cada uno de los modelos necesarios para la interfaz 3D se ha desarrollado en su
completitud, incorporndolo a la interfaz 3D con sus texturas y materiales correspondientes,
por lo que son completamente funcionales dentro del entorno. Estos modelos corresponden a
las calles con sus respectivos paraderos, los edificios, los vehculos y los clientes; por lo que
cualquier otro modelo 3D solo est relacionado con el acabado esttico de la interfaz y no
tiene incidencia directa con lo que realiza internamente el simulador.
Como se mencion anteriormente, la ciudad se ha creado como un nico objeto
(geometra 3D), en donde se ubican las calles y paraderos de manera esttica (ver Figura 8.2 y
8.3). Para el texturizado de los paraderos se utiliz un nico mapa UV, mientras que para las
calles se implement un mapa UV por tipo de calle, es decir, una imagen para la esquina de
una calle, otra imagen para el centro de una calle, otra para la interseccin entre dos calles,
etc., facilitando de esta forma el texturizado general del entorno.
Respecto a los vehculos (ver Figura 8.4), estos tambin se realizaron de forma esttica,
sin separar las geometras relativas a las ruedas con el resto del vehculo. A pesar de no ser un
proceso difcil de realizar e implementar, se opt por simplificar lo ms posible las diferentes
geometras del entorno a fin de no afectar el rendimiento final de la aplicacin, considerando
adems que esta se ejecuta en paralelo con el simulador de transporte, lo cual puede disminuir
drsticamente la cantidad de frames presentados por segundo (fps).
Respecto a la implementacin realizada mediante agentes, al momento de inicializar el
agente Manager3D se han establecido las propiedades iniciales de la pantalla, las cuales son:
ttulo de la ventana, su resolucin (800x600 pixeles), activacin de la sincronizacin vertical,
entre otros. Una vez finalizadas estas actividades, se procede a enviar la informacin del grafo
y los vehculos obtenidos a partir de sus respectivos archivos de texto al motor, para
posteriormente iniciar la ejecucin de la aplicacin, tal como se haba diseado en las
secciones previas.

100

Figura 8.2 Diseo modelo ciudad 3D [Elab. Propia]
Algunas de las tcnicas utilizadas por los motores grficos mencionadas en el apartado
3.4 aplicadas a la interfaz, han sido: la utilizacin de antialiasing para eliminar el dentado que
se produce en los bordes de las sombras, las cuales internamente han sido creadas utilizando
shadows maps; el uso de luces difusas para la creacin de la luz ambiental, y luces
direccionales para la luz solar; y finalmente la aplicacin de LODs en la generacin de la
ciudad, reduciendo su nivel de detalle a medida que el espectador se va alejando, lo que ha
tenido como consecuencia una mejora considerable en el rendimiento de la escena, liberando
gran parte el procesamiento que debe realizar el procesador para el renderizado final.
Sobre las tcnicas de modelado presentadas en el apartado 4.1, el modelado poligonal ha
sido la ms utilizada, tanto en la creacin de los edificios, como tambin en la creacin de los
vehculos, esto se debe principalmente a la estructura rgida que estas dos geometras poseen.
La tcnica de modelado mediante splines fue utilizada para la creacin de los clientes del
sistema de transporte (ver Figura 8.5), pero nicamente para el diseo de la cabeza, ya que la
parte restante se dise mediante el modelado poligonal. Hasta el momento no se ha utilizado
la tcnica de sculpting, debido a que no es de principal importancia el desarrollar modelos 3D
con un acabado esttico totalmente profesional (lo cual obviamente mejorara
considerablemente el acabado final de la interfaz).

101

Figura 8.3 Diseo modelo paradero 3D [Elab. Propia]

Figura 8.4 Diseo modelo vehculo 3D [Elab. Propia]

102
Cada uno de los vehculos y clientes se han cargado a partir de la informacin recopilada
por el agente Manager3D, el cual, como se mencion anteriormente, procesa dicha
informacin y luego procede a envirsela al motor grfico mediante la llamada de sus
diversos mtodos. En el caso de los clientes, se ha logrado modificar las funcionalidades del
agente TripGen, generando los modelos 3D de los clientes a medida que estos apareciendo en
el simulador. Los vehculos, al igual que los clientes, se han creado en conjunto con el
simulador (a partir del agente SchedGen), siendo necesario en ambos casos el tener que
reducir la velocidad de actualizacin para poder sincronizar la interfaz con las llamadas a
mtodos que est realizando el agente Manager3D.
El proceso de sincronizacin se logr mediante la pausa sucesiva de eventos como la
creacin de un cliente, la creacin de un vehculo, la solicitud de un nuevo recorrido, entre
otros; incorporando dichas pausas en bucles y mtodos que son llamados sucesivas veces,
como es el caso de los mtodos de actualizacin que poseen las clases que heredan de la clase
TickerBehaviour.

Figura 8.5 Diseo modelo cliente 3D en conjunto con su textura UV [Elab. Propia]

103
8.3 Interfaz Grfica de Usuario del Simulador
Cabe mencionar que el tamao de la pantalla se ha establecido de manera
predeterminada como una ventana y no en pantalla completa, ya que existe una interfaz
grfica de usuario (GUI) desarrollada para el simulador de transporte de pasajeros, con la cual
se puede obtener informacin ms detallada sobre las tareas que estn llevando a cabo los
agentes del sistema en todo momento.

Figura 8.6 Panel de actualizacin de eventos de la interfaz 3D [Elab. Propia]
Considerando la necesidad de un panel informativo que presente de forma oportuna los
diversos eventos que est realizando nicamente la interfaz 3D y su comunicacin con el
agente Manager3D, se ha extendido dicha GUI, aadiendo en esta nuevos paneles de datos.
En la Figura 8.6 se puede observar el panel de actualizacin de la interfaz 3D, denominada
Interface 3D Panel, en un comienzo muestra la informacin relacionada con la ventana en
la cual se est ejecutando el entorno tridimensional, informando sobre sus dimensiones, si se

104
encuentra a pantalla completa, el valor de antialiasing, la habilitacin de la sincronizacin
vertical, etc.
La mayor parte de la captura de informacin del Sistema Multiagente y su asignacin al
panel de informacin 3D se sincroniz pausando ambos sistemas, de esta forma se puede
observar una relacin entre los datos presentados por el Schedule Panel y los datos
presentados por la Interface 3D Panel, mejorando la presentacin de la sucesiva
informacin que se presenta en tiempos bastante cortos.

Figura 8.7 Propiedades del archivo de entrada modificable mediante panel [Elab. Propia]
En la Figura 8.7 se puede observar que en la segunda fila de opciones se ha incorporado
el modificador externo del archivo Adartw.ini relacionado con el uso o no uso de la interfaz
3D al momento de ejecutar el simulador de transporte. Al presionar el botn guardar en la
ventana de dialogo, se actualizan los resultados en el archivo correspondiente respecto a las
variables que han sido modificadas, y finalmente se cierra la ventana, quedando el archivo
final listo para ser utilizado por el simulador.

105
8.4 Rutas y Asignacin de Caminos
Ya que cada uno de los vehculos posee la capacidad de desplazarse por la ciudad, es
necesario implementar algn mtodo de seguimiento de rutas que se adecue a la informacin
recibida del simulador, considerando adems elementos propios de la interfaz, por ejemplo, la
rotacin del vehculo segn el sentido de la ruta en que se encuentre, el mantener una
velocidad constante en el cambio de rutas, entre otros.

Figura 8.8 Rutas mediante splines [Elab. Propia]
El motor grfico jMonkeyEngine permite la implementacin de splines para la
generacin de rutas y la asignacin de modelos 3D a dichas rutas, siendo modificable en ellos
atributos como la velocidad, cantidad de nodos en esa ruta, longitud del tramo, entre otros.
Cada una de estas rutas se define mediante la clase MotionPath, que posee la abstraccin
necesaria respecto a la utilizacin de vectores, simplificando en gran medida su comprensin y
facilidad de implementacin. En la Figura 8.8 se puede observar el modo de depuracin del
camino, siendo visible los nodos y conexiones entre dichos nodos, lo que permite que los
diferentes vehculos puedan cambiar su direccin y sentido respecto a la ruta actual en que se
encuentran, proceso realizado de forma automtica por la instancia de la clase MotionPath al
momento de asignar el vehculo a esa ruta.

106

Figura 8.9 Implementacin del pathfinding [Elab. Propia]
En la Figura 8.9 se puede observar la implementacin de una ruta, la cual va desde el
paradero 10 hasta el paradero 9 del motor. Como se mencion anteriormente, se hace uso de la
clase MotionPath para generar dicha ruta. A continuacin se describe mediante un cdigo
dicha implementacin:
MotionPath[] grafo_rutas = new MotionPath[82];

//P10 - P9
grafo_rutas[67].addWayPoint(new Vector3f(-27f, 0, 162.2f));
grafo_rutas[67].addWayPoint(new Vector3f(-63.2f, 0, 162.2f));
grafo_rutas[67].addWayPoint(new Vector3f(-63.2f, 0, 104.8f));
grafo_rutas[67].addWayPoint(new Vector3f(-113f, 0, 104.8f));

grafo_rutas[67].enableDebugShape(assetManager, rootNode);

En el cuadro anterior se ha definido una nueva ruta, la cual posee exactamente los cuatro
puntos definidos en la Figura 8.9. La incorporacin de los puntos se realiza mediante el
mtodo addWayPoint, al cual se le debe especificar las coordenadas x y z globales del
entorno tridimensional. Para poder visualizar la ruta, se hace uso del mtodo
enableDebugShape.
4
3
2
1

107
Para asignar un vehculo a la ruta creada previamente, se hace uso de la clase
MotionEvent, en donde se debe especificar el modelo tridimensional y la ruta a seguir.
Posterior a esto se especifican algunos datos adicionales, como la forma en que se comportar
la direccin del objeto al momento de seguir la ruta, siendo en este caso de manera total, es
decir, el modificar la direccin y el sentido del vehculo de acuerdo a la direccin y sentido de
la ruta. Otra caracterstica que se ver afectada es la rotacin de los vehculos, la cual se gira
en 90 (constante HALF_PI de la clase FastMath), la cual se realiza desde una perspectiva
cenital (constante UNIT_Y de la clase Vector3f).
MotionEvent motionControl = new MotionEvent(vehiculos[i].nodoSpatial,
grafo_rutas[67]);
motionControl.setDirectionType(MotionEvent.Direction.PathAndRotation);
motionControl.setRotation(new
Quaternion().fromAngleNormalAxis(FastMath.HALF_PI, Vector3f.UNIT_Y));
motionControl.setSpeed(VEL_BUS/grafo_rutas[pos].getLength());
motionControl.play();

La velocidad del bus se estableci de manera fija, esto se realiz dividiendo un valor fijo
constante por la longitud de la ruta a la cual se est asignando el vehculo, de esta forma,
independiente de la ruta a la cual el vehculo se ha asignado, mantendr la misma velocidad.
Finalmente se inicia el movimiento del vehculo en la ruta mediante la llamada del
mtodo play.
grafo_rutas[67].setPathSplineType(SplineType.Linear);

grafo_rutas[67].addListener(new MotionPathListener(){
public void onWayPointReach(MotionEvent control, int wayPointIndex){
if(control.getPath().getNbWayPoints() == wayPointIndex + 1){
//dentro se incorpora lo que se desea realizar con
//el vehculo.
}
}
});

Los comandos presentados en el recuadro anterior permiten por una parte generar lneas
rectas (SplineType.Linear), para evitar que las velocidades cambien debido a la curvatura de
las mismas, y tambin se hace uso de la clase MotionPathListener para determinar cuando un
vehculo ha finalizado una determinada ruta, comprobando si el nmero de nodos totales de
una ruta es igual al ndice del nodo en que se encuentra actualmente.

108

8.5 Interfaz Grfica de Usuario de la Interfaz 3D
Para incorporar paneles, botones, popup, cajas de mensaje, etc., se ha hecho uso del
plugin Nifty GUI, el cual se encuentra de manera interna en el motor grfico jMonkeyEngine.
Este permite incorporar interfaces grficas dentro de la ventana de la interfaz 3D, siendo
totalmente compatibles con elementos propios del motor, como las geometras que se
encuentran dentro del entorno, siendo posible incluso el crear interfaces en los polgonos de
dichas geometras. En este proyecto, especficamente se ha hecho uso de las cajas de texto
para mostrar cierta informacin, y submens con opciones, los cuales se despliegan al
momento de seleccionar algn cliente, vehculo o nodo de parada.

Figura 8.10 Men desplegable de la GUI 3D clientes y vehculos [Elab. Propia]
En la Figura 8.10 y 8.11 se puede observar el submen generado al momento de
seleccionar un vehculo, un cliente o nodo de parada; los cuales se generan a partir de la
seleccin de dicha entidad, esta seleccin se realiza mediante la utilizacin de la clase
ActionListener, correspondientes a los mtodos de entrada del mouse.
Permite establecer la cmara en primera
persona a la entidad seleccionada
Panel de informacin
Genera un evento de cancelacin
Cierra el sub-men

109

Figura 8.11 Men desplegable de la GUI 3D nodos de parada [Elab. Propia]

Figura 8.12 Caja de texto con informacin de los clientes de la GUI 3D [Elab. Propia]
En la Figura 8.12 se puede observar la generacin del panel de informacin que se
muestra al momento de ver los datos de un cliente. Este panel.se ha generado con la clase
WindowBuilder, la cual permite incorporar otros controles de la interfaz grfica de usuario
Nifty GUI.
Identificador del cliente
(otorgado por el motor grfico)
Nombre del cliente (otorgado por
el simulador de transporte)
Nodo en el cual comienza
Nodo al cual desea llegar
Estado del cliente

110
Cabe destacar que Nifty GUI se puede implementar mediante XML o mediante el Java
Builder que este posee (nicamente mediante cdigo Java), siendo en este caso utilizado el
ltimo mtodo, debido a la facilidad de uso que esta posee.
8.6 Modificaciones Anexas
Debido a la dificultad que implica el observar los vehculos y clientes en la ciudad
producida principalmente por la utilizacin de edificios con una altura relativamente grande,
se ha desarrollado una segunda modalidad de representar los diferentes edificios que
conforman la ciudad.

Figura 8.13 Edificios sin textura y con baja opacidad [Elab. Propia]
Esta modalidad consiste en la transformacin de los materiales actuales de cada uno de
los edificios de la ciudad a materiales menos llamativos, ocultando su textura y disminuyendo
su nivel de opacidad (ver Figura 8.13), simulando de esta forma algo similar a los rayos X.
Este material hace posible el ver a travs de los edificios y por consiguiente mejora la
visibilidad del espectador. Este proceso es reversible en la interfaz, lo que quiere decir que los

111
materiales de los edificios pueden devolverse a la normalidad en cualquier momento
presionando la tecla correspondiente. Tambin a dicho material se la ha desactivado la opcin
de recibir y generar sombras, manteniendo de esta forma un rendimiento razonable.
Otro de los puntos que se consideraron al momento de realizar este cambio en el
material de los edificios, es el permitir seleccionar los vehculos, clientes y nodos de parada a
travs de los edificios. Esto claramente permite trabajar de manera mucho ms fcil con la
interfaz de Nifty GUI y el entorno grfico.

Eliminado: h

112

Captulo 9: Conclusiones
Con la presente memoria se espera haber entregado una visin lo suficientemente
concreta respecto a los modelos e ideas presentadas, como tambin a la estructura de solucin
que se ha implementado hasta el momento. A continuacin se detallan de forma estructurada
las conclusiones obtenidas a partir del desarrollo de este proyecto.
9.1 Sobre los Diferentes Tpicos y su Integracin
Se ha logrado comprender cada uno de los temas involucrados para el desarrollo de una
aplicacin en comn. Respecto a la utilizacin de visualizadores tridimensionales, se han
identificado algunas ventajas en su implementacin sobre sistemas complejos, principalmente
en la comprensin de elementos que interactan internamente en un sistema.
Por otra parte, se ha analizado la gran utilidad que significa el uso de la tecnologa de
agentes en la resolucin de problemas, en especial cuando el conjunto de elementos que
interactan en el sistema trabajan de forma distribuida, a velocidades muy altas, o incluso en
paralelo. De esta forma, tanto la Visualizacin 3D como los Sistemas Multiagente otorgan una
base para el desarrollo de aplicaciones robustas y completas, las cuales pueden comenzar
desde la lgica resolutiva del problema a desarrollar, y llegar hasta la generacin de interfaces
tridimensionales interactivas para su comprensin.
En el caso de los sistemas flexibles de transporte, especficamente los de respuesta a
demanda, existe una gran cantidad de elementos que interactan entre s, por lo que se genera
cierta complicacin en su comprensin, si adems se considera su planteamiento mediante la
utilizacin de la tecnologa de agentes, se le incorporan muchas ms caractersticas,
terminando finalmente en un sistema bastante complejo. Al incorporar las caractersticas de la
interfaz 3D, se le permite al usuario analizar de manera enfocada los diferentes elementos que
se encuentran funcionando, sin tener que verificar cada uno de ellos, por ejemplo, se puede
analizar la frecuencia de salidas o asignacin de vehculos, o mantener un ruteo de las
diferentes posiciones en que se encuentran los clientes, etc.
9.2 Sobre los Objetivos Cumplidos
En consideracin de todo lo anteriormente expuesto, y tomando en cuenta el objetivo
principal del proyecto, se realizaron una serie de pasos que permitieron adaptarse de mejor
forma a la metodologa de trabajo escogida y cumplir con los tiempos propuestos en la fase de
planificacin del proyecto. A continuacin se explican de forma generalizada cada uno de los
pasos:
Eliminado: el presente informe
Eliminado:

113
1) El anlisis general enfocado a los componentes del simulador de transporte que tienen
directa relacin con una posible representacin en la interfaz grfica, todo esto a fin de
simplificar y mejorar la forma de representar la informacin relativa a ellos. Aqu se
considera todo el proceso de anlisis de los diferentes tpicos del proyecto y el
establecimiento de la conexin que hay entre ellos.
2) Definicin de la estructura general de la ciudad y los elementos que la componen, en
la cual transitarn los diferentes vehculos, considerando adems los nodos (paraderos)
en donde estos puedan recoger o bajar clientes. Todo esto basado en un exhaustivo
proceso de diseo, tanto del Sistema Multiagente como del motor grfico.
3) Creacin de los diferentes elementos 3D que componen la escena en su totalidad, para
luego centrarse nicamente en la lgica que debe ser implementada.
4) Informar de los diferentes acontecimientos efectuados en el simulador de transporte al
agente encargado de administrar la interfaz grfica, permitiendo de esta forma procesar
la informacin y adaptarla para su posterior representacin.
5) Enviar la informacin procesada al motor grfico, el cual genera los cambios
necesarios tanto en los elementos que son visibles para el usuario (movimiento de un
bus, desaparicin de un cliente, generacin de los edificios, etc.), y tambin los que se
centran en la lgica de la interfaz (obtencin de la prxima ruta a asignar al bus,
ubicacin interna de los caminos, calcular rotaciones y traslaciones, etc.).
6) Establecer los elementos necesarios para poder inducir nuevas acciones en el Sistema
Multiagente, basado en las necesidades del usuario.
7) Generar los eventos, ya sea en los clientes o en los vehculos correspondientes, y luego
enviar dicha informacin al administrador de la interfaz grfica (volviendo nuevamente
al paso 4).
A medida que se empezaron a desarrollar diversos prototipos, se fueron implementando
nuevas funcionalidades, como la capacidad de cambiar el material de los edificios o la
utilizacin de rutas ya definidas por el motor grfico para simplificar el proceso de
implementacin, lo que en general conlleva a una mejora bastante importante en relacin a la
funcionalidad del sistema, mejorando adems la experiencia del usuario final.
Respecto al motor grfico jMonkeyEngine (JME), gracias a su entorno de desarrollo
basado en el IDE Netbeans, se han facilitado bastante los procesos de depuracin e
implementacin de los diferentes modelos 3D, los cuales pueden ser analizados y modificados
directamente en el entorno de desarrollo, sin tener que compilar y ejecutar la aplicacin cada
vez que se requiera. Adems, no se han producido grandes inconvenientes en la integracin
del Sistema Multiagente basado en la plataforma de desarrollo de agentes JADE y las clases
vietas

114
definidas por JME, debido principalmente a la utilizacin en ambas plataformas del lenguaje
de programacin Java.
Debido a la naturaleza misma del proyecto, el diseo realizado de las pruebas se ha
utilizado nicamente para validar las funcionalidades propuestas, por lo que no se ha realizado
una seccin que trate nicamente de la evaluacin de resultados de las mismas.
9.3 Sobre el Trabajo Futuro
Como se mencion anteriormente, el diseo de la ciudad y el conjunto de paraderos,
edificios, veredas, entre otros; han sido pensados de manera esttica, por lo que el Sistema
Multiagente se adeca de manera fija a este, sin permitir el crear por ejemplo una ciudad con
nodos adaptables al archivo que almacena el grafo de la ciudad. Una posible mejora a realizar
a la interfaz es la lectura de dicho archivo y la generacin automtica de todos los elementos
que conforman la interfaz tridimensional.
Adems, el entorno grfico ha sido implementado en base a un simulador de transporte
que hace uso del framework MADARP, por lo que podra considerarse una adaptacin del
visualizador tridimensional nicamente al framework, generando los elementos bsicos que
permitan crear el escenario 3D base para cualquier simulador que se desee implementar.

115

Referencias
[Ahokas, 2002] Timo Ahokas, Shadow Maps, Helsinki University of Technology,
Telecommunications Software and Multimedia Laboratory, HUT TML 2002, Tik-110-500
Seminar on Computer Graphics, 2002.
[Austin, 1962] J. L. Austin, How to do things with word, Harvard University Press,
Cambridge, Massachusetts, 1962, pp 124-164.
[Baranlloni, 2009] Felipe Baranlloni, Visualizacin 3D de Sistema Multiagente Aplicado al
Problema de Transporte de Pasajeros, Pontificia Universidad Catlica de Valparaso, Tesis
de Grado de Magster en Ingeniera Informtica, 2009.
[Bauer et al., 2001] Bernhard Bauer, Jrg P. Mller, James Odell, Agent UML: A Formalism
for Specifying Multiagent Interaction, Springer-Verlag, Berln, 2001, pp 91-103.
[Bellifemine et al., 2001] Fabio Bellifemine, Agostino Poggi, Giovanni Rimassa, Developing
Multi-agent Systems with JADE, 2001, pp 30-32.
[Brooks, 1985] Rodney A. Brooks, A Robust Layered Control System for a Mobile Robot,
Massachusetts Institute of Technology, Artificial Intelligence Laboratory, A.I. Memo 864,
1985.
[Brooks, 1991] Rodney A. Brooks, Intelligence Without Reason, Cambridge, MIT Artificial
Intelligence Lab, A.I. Memo 1293, 1991.
[Burrafato y Cossentino, 2002] Piermarco Burrafato, Massimo Cossentino, Designing a
multi-agent solution for a bookstore with the PASSI methodology, Dipartimento di
Ingegneria Informatica, Centro di studio sulle Reti di Elaboratori-Consiglio Nazionale delle
Ricerche c/o CUC, CiteSeer Computer and Information Science, 2002.
[Cans et al., 2003] Jos H. Cans, Patricio Letelier, M Carmen, Metodologas giles en el
Desarrollo de Software, Universidad Politcnica de Valencia, Taller VIII Jornadas de
Ingeniera del Software y Bases de Datos, JISBD, 2003.
[Castillo et al., 2010] Luis F. Castillo, Oscar H. Franco, Jaime A. Giraldo, Agentes basados
en Ontologas para la Web Semntica, Universidad Nacional de Colombia, Quinto Congreso
Colombiano de Computacin, 2010.
[Cordeau y Laporte, 2002] Jean-Franois Cordeau, Gilbert Laporte, The Dial-a-Ride
Problem (DARP): Variants, Modeling issues and algorithms, Canada, Quarterly Journal of
the Belgian, 2002.
Comentario [cc1]: Gran parte
de las referencias estan
incompletas

Paper conferencia:
Autores, titulo, evento, fecha
ypaginas

Paper revista:
Autores, titulo, revista,
volumen/numero, ao

Libro:
Autores, titulo, editorial, ao
Eliminado: Magister
Comentario [cc2]: No y titulo
del volumen
Comentario [cc3]: Que es?
Paper en conferencia, revista o
libro? Editorial?
Comentario [cc4]: Esta la
revista pero no el volumen/issue y
paginas

116
[Cubillos, 2005] Claudio Cubillos, MADARP: Multi-Agent Framework for Transportation
Systems, Politecnico di Torino, Tesis Doctoral en Informtica, 2005.
[Donoso y Sandoval, 2009] Makarena Donoso, Daniel Sandoval, Desarrollo de un Sistema
Multiagente para el Dynamic Dial-a-Ride Problema (D-DARP), utilizando Tecnologa de
Agentes, Pontificia Universidad Catlica de Valparaso, Proyecto de Ttulo en Ingeniera de
Ejecucin Informtica, 2009.
[Engel et al., 2008] Wolfgang Engel, Jack Hoxley, Ralf Kornmann, Niko Suni, Jason Zink,
Programming Vertex, Geometry, and Pixel Shaders, Second Edition , 2008, pp 18-20.
[Engel y Geva, 2000] Wolfgang Engel, Amir Geva, Beginning Direct3D Game
Programming, 2000, pp 3-6.
[Ezequiel, 2004] Mario Ezequiel, Uso de tecnologas de hardware grfico en el apoyo al
realismo en entornos virtuales arquitectnicos, Universidad de Colima, Colima, Mxico,
Tesis Posgrado Telemtica, 2004.
[Finin et al., 1995] Tim Finin, Yannis Labrou, James Mayfield, KQML as an agent
communication language, University of Maryland Baltimore, Third International Conference
on Information and Knowledge Managment, 1995.
[Garro, 2012] Alfredo Garro, Modeling-Notation Source: GAIA, Official Guide Document
AUML, 2012.
[Glassner, 1989] Andrew Glassner, An Introduction to Ray Tracing, San Francisco, 1989,
pp 4-10.
[Gmez et al., 1999] Pedro Gmez, Marco Gmez, Enrique Alonzo, Funcionamiento de los
rboles BSP, 1999.
[Goodridge et al., 1994] Goodridge, S. G.; Luo, R. C., Fuzzy Behavior Fusion for Reactive
Control of an Autonomous Mobile Robot: MARGE, Conference Publication, 1994.
[Gregory et al., 2009] Jason Gregory, Jeff Lander, Matt Whiting, Game Engine
Architecture, 2009, pp 411-477.
[Hearn y Baker, 2005] Donald Hearn, M. Pauline Baker, Grficos por computadora con
OpenGL, 2005, pp 81-82.
[Hess, 2010] Roland Hess, Blender Foundations: The Essential Guide to Learning Blender
2.6, 2010, pp 1-15.

117
[Hpola y Vargas-Quesada, 2005] Pedro Hpola, Benjamn Vargas-Quesada, Agentes
inteligentes: definicin y tipologa. Los agentes de informacin, Revista internacional
cientfica y profesional, 2005.
[Keller, 2011] Erick Keller, Introducing Zbrush 4, SYBEX, 2011, pp 15-30.
[Maroto, 2005] Joaqun Maroto Ibez, Metodologa para la generacin de entornos
virtuales distribuidos y su aplicacin a simuladores de conduccin, Universidad Politcnica
de Madrid, Tesis Doctoral en Ingeniera Mecnica, 2005.
[Mas, 2005] Ana Mas, Agentes Software y Sistemas Multi-Agente: Conceptos, arquitecturas
y aplicaciones, 2005, pp 10-160.
[Mller et al., 1995] Mller, J. P., Pischel, M. and Thiel, M, Modelling reactive behaviour in
vertically layered agent architectures, Lecture Notes in Computer Science, 1995.
[Navarra y Martnez, 2006] Pablo Navarra, Jos Martnez, Agentes inteligentes en la
bsqueda y recuperacin de informacin, 2006, pp 50-55.
[Odell et al., 2003] James J. Odell, H. Van Dyke Parunak, Mitch Fleischer, Sven Brueckner,
Modeling Agents and their Environment, Journal of Object Technology, 2003.
[Picco, 2009] Alexio Picco, City of Genoa and the flexible on demand transport systems:
an innovative way of moving, CIVITTAS, Transport System Guide, 2009.
[Prabhudas, 2008] Siddharth Prabhudas, Agile Unified Process, UnitedHealth Group
Information Services, Haryana, 2008, pp 2-3.
[Reddy, 2011] Martin Reddy, API design for C++, 2011, pp 10-50.
[Rodrguez et al., 2003] Alonso Rodrguez, Campillo Tomico, Prez Crespo, Radiosidad:
Grficos y Visualizacin 3D, Universidad Rey Juan Carlos, Escuela Superior de Ciencias
Experimentales y Tecnologa, 2003, pp 8-15.
[Rudowsky, 2004] Ira Rudowsky, Intelligent Agents, Brooklyn College, Communications
of the Association for Information Systems, Volume 14, 2004, pp 275-290.
[Rusell y Norvig, 1995] Stuart Rusell, Peter Norvig, Artificial Intelligence: A Modern
Approach, 2nd Edition, 1995, pp 32-46.
[Salazar, 2003] Lic. Carla Salazar Serrudo, Agentes y Multiagentes Inteligentes: Conceptos,
Arquitecturas y Aplicaciones, Universidad Mayor de San Simn, 2003, pp 7-23.
[Shreiner et al., 2008] Dave Shreiner, Mason Woo, Jackie Neider, Tom Davis, OpenGL
Programming Guide Sixth Edition, 2008, pp 10-22.

118
[Thomson, 2006] Richard Thomson, The Direct3D Graphics Pipeline, 2006, pp 43-58.
[Valient, 2001] Michal Valient, 3D Engines in games Introduction, Guide, 2001, pp 1-6.
[Wesson y Hayes-Roth, 1980] R Wesson, F. Hayes-Roth, Network Structures for Distributed
Situation Assessment, Defense Advanced Research Projects Agency, 1980, pp 1-28.
[Wood y DeLoach, 2001] Mark F. Wood, Scott A. DeLoach, An Overview of the Multiagent
Systems Engineering Methodology, Department of Electrical and Computer Engineering Air
Force Institute of Technology, First International Workshop on Agent-Oriented Software
Engineering, 2001.
[Wooldridge, 1996] Michael Wooldridge, An Introduction to MultiAgent Systems,
Department of Computer Science, University of Liverpool, UK, 1996, pp 1-101.
[Wright et al., 2007] Richard S. Wright, Jr., Benjamin Lipchak, Nicholas Haemel, OpenGL
SuperBible 4
th
Edition, 2007, pp 1-23.
[Wright y Lipchak, 2004] Richard S. Wright, Jr., Benjamin Lipchak, OpenGL SuperBible,
2004, pp 5-30.
[URL 1, 2005] Agile Unified Process, Pgina Web:
http://www.ambysoft.com/unifiedprocess/agileUP.html, 2005.
[URL 2, 2010] Agente RAE, Pgina Web:
http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=agente, 2010.
[URL 3, 2012] Adaptive VSync, Web Page: http://www.pcper.com/reviews/Graphics-
Cards/NVIDIA-GeForce-GTX-680-2GB-Graphics-Card-Review-Kepler-Motion/Adaptive-
VSync, 2012.
[URL 4, 2011] rboles BSP, Pgina Web: http://blogs.aerys.in/jeanmarc-leroux/tag/quake-3/,
2011.
[URL 5, 2000] 3D Pipeline, Pgina Web: http://www.anandtech.com/show/558/3, 2000.
[URL 6, 2009] Classical LOD Algorithms, Pgina Web: http://habib.wikidot.com/techniques,
2009.
[URL 7, 2012] Radiosidad, Pgina Web:
http://wiki.blender.org/index.php/Doc:ES/2.4/Manual/Lighting/Radiosity, 2012.
[URL 8, 2012] Irrlicht, Pgina Web: http://irrlicht.sourceforge.net/, 2012.
[URL 9, 2012] Panda3D, Pgina Web: http://www.panda3d.org/, 2012.
[URL 10, 2012] Ogre3D, Pgina Web: http://www.ogre3d.org/, 2012.

119
[URL 11, 2012] Crystal Space, Pgina Web: http://www.crystalspace3d.org/main/Main_Page,
2012.
[URL 12, 2012] Unity3D, Pgina Web: http://unity3d.com/, 2012.
[URL 13, 2012] UDK, Pgina Web: http://udk.com/, 2012.
[URL 14, 2012] jMonkeyEngine, Pgina Web: http://jmonkeyengine.com/, 2012.
[URL 15, 2006] Box Modeling, Pgina Web:
http://wiki.cgsociety.org/index.php/Modeling_a_foot, 2006.
[URL 16, 2004] NURB Modeling, Pgina Web: http://www.3dmax-
tutorials.com/_2_Rail_Sweep_Surface.html, 2004.
[URL 17, 2011] Perfiles de Splines, Pgina Web:
http://www.etereaestudios.com/training_img/subd_tips/introduccion.htm, 2011.
[URL 18, 2011] Sculpting, Pgina Web: http://estab1986.com/blog/tag/hard-surface-sculpting,
2011.
[URL 19, 2008] Texturizado, Pgina Web: http://ptex.us/ptexpaper.html, 2008.
[URL 20, 2009] Texturas Procedurales, Pgina Web:
http://www.oocities.org/valcoey/texturas_procedurales.html, 2009.
[URL 21, 2012] Vertex Paint, Pgina Web:
http://wiki.blender.org/index.php/Doc:2.4/Manual/Materials/Vertex_Paint, 2012.
[URL 22, 2009] Vertex Paint, Pgina Web: http://www.blender.org/development/release-
logs/blender-256-beta/brushes/, 2009.
[URL 23, 2006] UV Map, Pgina Web:
http://www.members.shaw.ca/nickyart/Comp/Camel.htm, 2006.
[URL 24, 2012] 3D Studio Max, Pgina Web: http://usa.autodesk.com/3ds-max/, 2012.
[URL 25, 2012] Maya, Pgina Web: http://usa.autodesk.com/maya/, 2012.
[URL 26, 2012] Google SketchUp, Pgina Web: http://sketchup.google.com/intl/es/, 2012.
[URL 27, 2012] Cinema 4D, Pgina Web: http://www.maxon.net/es/products/cinema-4d-
studio.html, 2012.
[URL 28, 2012] Zbrush, Pgina Web: http://www.pixologic.com/home.php, 2012.
[URL 29, 2012] Blender, Pgina Web: http://www.blender.org/, 2012.

Anexos
A: Ontologa del dominio proyecto relacionado
Cancelacion
<<concept>>
-Motivo: String
Evento
<<concept>>
-tipoEvento: String
CancelacionVehiculo
<<concept>>
-IDVehiculo: String
CancelacionCliente
<<concept>>
-IDCliente: String
EventoFallaVehiculo
<<concept>>
-IDVehiculo: String
-Motivo: String
EventoRetraso
<<concept>>
-Duracion: Date
-Motivo: String
EventoConfirmacion
<<concept>>
-IDConfirmacion: String
-Confirmacion: Boolean
-HoraConfirmacion: Date
EventoTrafico
<<concept>>
-Hora: Date
-Duracion: Date
-PuntosAfectados: PuntoCubierto
Congestion
<<concept>>
Desvio
<<concept>>
RetrasoVehiculo
<<concept>>
-IDVehiculo: String
RetrasoCliente
<<concept>>
-IDCliente: String
AusenciaPasajero
<<concept>>
PresenciaPasajero
<<concept>>
Viaje
<<concept>>
-Cliente: Solicitante
-Ruta: PuntoCubierto
PuntoCubierto
<<concept>>
-IDNodo: String
-DireccionReal: String
Solicitante
<<concept>>
-IDSolicitante: String
-ApellidoPaterno: String
-ApellidoMaterno: String
-Nombres: String
-Direccion: String
-Ciudad: String
-Fono: String
FuncionUtilidad
<<concept>>
Proveedor
<<concept>>
-IDVehiculo: String
-Modelo: String
-NumeroMotor: String
-TipoVehiculo: TipoVehiculo
-HorarioServicio: Horario
PropiedadUtilidad
<<concept>>
-TipoPropiedad: Propiedad
-Peso: float
Horario
<<concept>>
-Inicio: Date
-Termino: Date
PerfilSolicitudViaje
<<concept>>
-FechaViaje: Date
-Cliente: Solicitante
-PropVehiculo: PropiedadVehiculo
-PropViaje: PropiedadViaje
PerfilServicio
<<concept>>
-IDServicio: String
-Caracteristicas: PropiedadVehiculo
TipoVehiculo
<<concept>>
-Capacidad: int
-TipoVehiculo: String
PropiedadVehiculo
<<concept>>
-EsCompartido: boolean
-TieneAireAcondicionado: boolean
-TienePisoBajo: boolean
-TieneLuzParaLectura: boolean
-TieneRackEquipaje: boolean
-TieneRackBicicleta: boolean
-TieneRackSillaDeRuedas: boolean
PropiedadViaje
<<concept>>
PerfilViaje
<<concept>>
PerfilPropuestaViaje
<<concept>>
-PropVehiculo: PropiedadVehiculo
Duracion
<<concept>>
-DuracionActual: Date
-TiempoServicioEncuentro: Date
-TiempoServicioDestino: Date
-TiempoExcesoViajeCliente: Date
-MaximoTiempoViaje: Date
-TotalTiempoExcesoViaje: Date
-TotalTiempoViajeVehiculo: Date
-TiempoEsperaCliente: Date
AsientosRequeridos
<<concept>>
-Valor: int
Hora
<<concept>>
-HoraActual: Date
-HoraEncuentroMinima: Date
-HoraEncuentroMaxima: Date
-HoraDestinoMinima: Date
-HoraDestinoMaxima: Date
Direccion
<<concept>>
-Valor: PuntoCubierto
-DireccionEncuentro: String
-DireccionDestino: String

Figura A.1 Ontologa del dominio proyecto relacionado [Donoso y Sandoval, 2009]
Unidos), No revisar la ortografa
ni la gramtica

Informe Final Proyecto de Título MARZO 2013 Rev CCFX

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Informe Final Proyecto de Título MARZO 2013 Rev CCFX

Transféré par

Droits d'auteur :

Formats disponibles

PONTIFICIA UNIVERSIDAD CATLICA DE VALPARASO

Vous aimerez peut-être aussi