Informe Final Proyecto de Título MARZO 2013 Rev Ccfx

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA INFORMÁTICA

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 TÍTULO PROFESIONAL DE INGENIERO DE EJECUCIÓN EN INFORMÁTICA

PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA INFORMÁTICA

MARZO 2013

Visualizador Tridimensional para un Sistema Multiagente aplicado al Problema

de Transporte de Pasajeros

GERARDO ISMAEL URBINA AMPUERO

Profesor Guía: Claudio Cubillos Figueroa

Profesor Co-Referente: Ricardo Soto De Giorgis

Carrera: Ingeniería de Ejecución en Informática

Dedicado a mis padres, familiares y amigos, por su apoyo incondicional a lo largo de todo este proceso, permitiéndome 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

Capítulo 1: Descripción del Tema............................................................................................1

1.1 Introducción ........................................................................................................................... 1

1.2 Definición de Objetivos.......................................................................................................... 2

1.2.1 Objetivo General....................................................................................................................... 2

1.2.2 Objetivos Específicos................................................................................................................ 2

1.3 Planificación del Proyecto ..................................................................................................... 2

1.4 Metodología 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

Capítulo 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 Tipología de Agentes............................................................................................................12

2.4 Sistemas Multiagente ...........................................................................................................13

2.5 Arquitecturas para la Construcción de Agentes ...............................................................14

2.5.1 Deliberativas ...........................................................................................................................15

2.5.2 Reactivas .................................................................................................................................16

2.5.3 Híbridas...................................................................................................................................17

2.6 Infraestructura de Agentes .................................................................................................19

2.6.1 Ontologías...............................................................................................................................19

2.6.2 Lenguajes de Comunicación para Agentes (ACL)..................................................................19

2.6.2.1 KQML ......................................................................................................................................20

2.6.2.2 FIPA ACL.................................................................................................................................21

2.6.3 Protocolos de Interacción para Agentes (AIP) ........................................................................21

2.6.3.1 FIPA IPs ...................................................................................................................................22

2.7 Metodologías 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

Capítulo 3: Motores Gráficos 3D ...........................................................................................30

3.1 ¿Qué es un Motor Gráfico?.................................................................................................30

3.2 APIs Gráficas .......................................................................................................................30

3.2.1 OpenGL ..................................................................................................................................31

3.2.2 Direct3D..................................................................................................................................31

3.3 Representación Tridimensional de Geometrías ................................................................32

3.4 Técnicas Utilizadas por Motores Gráficos 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 Iluminación y Transformación (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 Gráficos 3D.........................................................................................40

Capítulo 4: Modelado 3D........................................................................................................42

4.1 Técnicas 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 Técnicas 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

Capítulo 5: Selección 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

Capítulo 6: Desarrollo del Proyecto.......................................................................................60

6.1 Presentación del Caso de Estudio .......................................................................................60

6.1.1 Problemas Relacionados .........................................................................................................60

6.1.2 Tecnologías Utilizadas............................................................................................................61

6.1.3 Desarrollo del Caso de Estudio...............................................................................................61

6.2 Diseño del Sistema................................................................................................................ 62

6.2.1 Análisis del Sistema Existente ................................................................................................ 62

6.2.2 Modelo Requerimientos del Sistema ...................................................................................... 64

6.2.2.1 Identificación de Agentes .........................................................................................................64

6.2.2.2 Identificación de Roles .............................................................................................................66

6.2.2.3 Especificación de Tareas...........................................................................................................69

6.2.3 Modelo de Sociedad de Agentes ............................................................................................. 70

6.2.3.1 Descripción de Ontología de Comunicación.............................................................................71

6.2.3.2 Descripción de Roles ................................................................................................................72

6.2.4 Modelo de Implementación de Agentes..................................................................................73

6.2.4.1 Definición de la Estructura Multiagente ...................................................................................73

6.2.4.2 Definición de la Estructura de los Agentes Individuales...........................................................75

6.2.4.3 Datos de Entrada.......................................................................................................................78

6.2.5 Diseño Motor Gráfico .............................................................................................................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 Diseño de la Ciudad ................................................................................................................ 85

Capítulo 7: Pruebas de Software............................................................................................87

7.1 Planificación de las Pruebas................................................................................................ 88

7.2 Diseño de las Pruebas ..........................................................................................................88

7.3 Datos de Prueba ................................................................................................................... 92

Capítulo 8: Implementación ...................................................................................................98

8.1 Conexión entre el SMA y el Motor Gráfico.......................................................................98

8.2 Desarrollo e Integración de Modelos 3D............................................................................99

8.3 Interfaz Gráfica 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 Asignación de Caminos........................................................................................105

8.5 Interfaz Gráfica de Usuario de la Interfaz 3D.................................................................108

8.6 Modificaciones Anexas ......................................................................................................110

Capítulo 9: Conclusiones ......................................................................................................112

9.1 Sobre los Diferentes Tópicos y su Integración.................................................................112

9.2 Sobre los Objetivos Cumplidos.........................................................................................112

9.3 Sobre el Trabajo Futuro....................................................................................................114

Referencias .............................................................................................................................115

Anexos……………………………………………………………………………………….......

A: Ontología 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 Interacción 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 subsunción [Brooks, 1985].............................................................17

Figura 2.5 Arquitecturas de agente por capas [Müller 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 metodología PASSI [Burrafato y Cossentino, 2002] .......................26

Figura 3.1 Elementos básicos de una geometría [Elab. Propia] ................................................32

Figura 3.2 Ejemplo polígonos con triángulos [Ezequiel, 2004] ................................................33

Figura 3.3 Primitivas geométricas básicas [Elab. Propia] .........................................................34

Figura 3.4 Ejemplo de error en sincronización 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 transformación 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 Utilización 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 Identificación 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 Descripción del dominio proyecto relacionado [Donoso y Sandoval, 2009]...........63

Figura 6.2 Diagrama de identificación 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 información inicial [Elab. Propia].....................................67 Figura 6.4 Escenario de generación de evento en vehículo [Elab. Propia] ...............................68

Figura 6.5 Escenario de generación de evento en cliente [Elab. Propia] ..................................69 Figura 6.6 Especificación de tareas [Elab. Propia]....................................................................70 Figura 6.7 Descripción de ontología de comunicación [Elab. Propia]......................................71 Figura 6.8 Descripción de roles [Elab. Propia] .........................................................................72

Figura 6.9 Definición de la estructura Sistema Multiagente [Elab. Propia]..............................74

Figura 6.10 Definición de la estructura agente Manager3D [Elab. Propia] ..............................76

Figura 6.11 Definición de la estructura agente TripGen [Elab. Propia]....................................77 Figura 6.12 Definición de la estructura agente SchedGen [Elab. Propia].................................77

Figura 6.13 Definición de la estructura agente EventVehicle [Elab. Propia]............................78

Figura 6.14 Definición 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 Conexión entre SMA y el motor gráfico [Elab. Propia] ..........................................98

Figura 8.2 Diseño modelo ciudad 3D [Elab. Propia] ..............................................................100 Figura 8.3 Diseño modelo paradero 3D [Elab. Propia]...........................................................101 Figura 8.4 Diseño modelo vehículo 3D [Elab. Propia]...........................................................101 Figura 8.5 Diseño modelo cliente 3D en conjunto con su textura UV [Elab. Propia] ............102 Figura 8.6 Panel de actualización 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 Implementación del pathfinding [Elab. Propia] .....................................................106 Figura 8.10 Menú desplegable de la GUI 3D clientes y vehículos [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 información 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 Ontología 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 inicialización de datos [Donoso y Sandoval, 2009] ...............................79

Tabla 7.1 Prueba activación/desactivación VSync [Elab. Propia] ............................................89 Tabla 7.2 Prueba cambios en resolución de la pantalla [Elab. Propia] .....................................89 Tabla 7.3 Prueba aumento/disminución calidad antialiasing [Elab. Propia].............................89

Tabla 7.4 Prueba iniciación y carga de modelos 3D [Elab. Propia]..........................................90 Tabla 7.5 Prueba creación de luces y sombras [Elab. Propia]...................................................90 Tabla 7.6 Prueba creación de la música ambiental [Elab. Propia] ............................................90 Tabla 7.7 Prueba aplicación del Path Finding [Elab. Propia]....................................................91 Tabla 7.8 Prueba creación del skybox [Elab. Propia]................................................................91 Tabla 7.9 Prueba modificación de la cámara [Elab. Propia] .....................................................92 Tabla 7.10 Prueba captura de evento [Elab. Propia] .................................................................92 Tabla 7.11 Prueba generación 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 visualización 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 utilización de una interfaz 3D permite comprender con mayor facilidad las diversas comunicaciones e interacciones que realizan los agentes entre si, otorgándole a cada uno de ellos una representación propia en el mundo virtual. El objetivo de este proyecto, además de crear dicha interfaz, es otorgar un medio de interacción 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: Visualización 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

Capítulo 1: Descripción del Tema

1.1 Introducción

La utilización de agentes en la resolución 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 interactúan unos con otros, e intercambian mensajes, se está refiriendo a un Sistema Multiagente (MAS).

Debido a la gran cantidad de elementos que conforman la tecnología de agentes, en muchas ocasiones se hace uso de interfaces de monitoreo, las cuales consisten en una serie de paneles que entregan información general sobre el funcionamiento del sistema. En el desarrollo de aplicaciones con una magnitud considerable, esta información no es suficiente para comprender exactamente cada una de las comunicaciones realizadas por los diversos agentes, siendo necesaria la utilización de interfaces con un mayor grado de complejidad.

Es por esto, que en el siguiente proyecto se propone la realización de una interfaz 3D, la cual permitirá representar de forma gráfica los componentes más importantes del sistema seleccionado, además de las interacciones y el intercambio de mensajes que realizan los agentes. A su vez, también se propone un medio de interacción 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, también se ha considerado el aspecto estético de la misma, es decir, realizar un mundo que posea elementos característicos del sistema en el cual se está trabajando.

Debido a que la implementación 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 interactúan principalmente dos actores: vehículos y clientes. En este sistema, se busca solucionar los típicos problemas producidos en el transporte urbano e interurbano mediante la utilización de diversos dispositivos tecnológicos, considerando además un recorrido adaptable a las diversas demandas de transporte y tipos de servicios solicitados por los diferentes clientes.

Eliminado: , e

2

1.2 Definición de Objetivos

1.2.1 Objetivo General

Desarrollar una interfaz tridimensional que represente gráficamente un Sistema Multiagente aplicado al problema de transporte de pasajeros, utilizando el motor jMonkeyEngine para la visualización del mundo 3D y JADE como plataforma para el desarrollo de agentes.

1.2.2 Objetivos Específicos

• Comprender el funcionamiento de los Sistemas Multiagente en conjunto con el sistema de transporte de pasajeros seleccionado.

• Comprender el uso de herramientas para la creación de modelos 3D y la forma de incorporar dichos modelos al motor gráfico seleccionado.

• Realizar el diseño del sistema.

• Implementar la interfaz tridimensional del Sistema Multiagente.

• Realizar pruebas del sistema.

1.3 Planificación del Proyecto

La planificación del proyecto pretende estructurar las diferentes actividades e hitos que forman parte del proyecto. Una buena planificación 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 planificación del proyecto fue dividida en cuatro etapas, las cuales son:

1) Recolección de información y análisis investigativo: En esta etapa, se realiza todo el proceso de investigación y recolección de información correspondiente a las diferentes áreas abordadas en este proyecto: Sistemas Multiagente, Motores Gráficos, Sistemas de Transporte de Pasajeros, ente otros.

2) Diseño y desarrollo de prototipos: Una vez finalizado el proceso de recolección e investigación, se procede a realizar el diseño del sistema en conjunto con el desarrollo de diversos prototipos incrementales. Esto permite validar tanto el diseño, como el funcionamiento de las diversas tecnologías aplicadas en la resolución del problema.

Con formato: Numeración yviñetas

Eliminado: Investigar

Eliminado: Investigar

Eliminado:

3

3) Integración e implementación: Se integran e implementan los diferentes prototipos y diseños creados en la etapa anterior, permitiendo de esta forma, realizar en la etapa siguiente las pruebas y validaciones correspondientes.

4) Pruebas y validaciones de aplicación: Se realizan pruebas exhaustivas sobre la aplicación 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 término

Con formato: Inglés (EstadosUnidos), No revisar laortografía ni la gramática

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 Metodología de Trabajo

Para el desarrollo de este proyecto se ha decidido utilizar el modelo de proceso de software Agile UP (AUP). Esta metodología básicamente otorga un proceso simple y fácil de entender para el desarrollo de software mediante diversos conceptos y técnicas rescatadas de la Metodología Ágil y Rational UP (RUP) [URL 1, 2005]. RUP es considerado como una herramienta rígida y conducida por la metodología en cascada, por lo cual se ha flexibilizado con el fin de poder adaptarse a proyectos cambiantes y de tamaños moderados (respecto a tiempo y recursos), surgiendo de esta forma AUP [Prabhudas, 2008], [Canós et al., 2003]. En la Figura 1.1 se puede observar el ciclo de vida de esta metodología, 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 metodología AUP implica descomponerse en fases seriales, esto quiere decir, que cada fase se realiza una tras otra, manteniendo siempre la relación que estas poseen. A continuación se describen las cuatro fases que lo componen [Prabhudas, 2008]:

1) Iniciación: Se establece el alcance inicial del proyecto, se priorizan los requerimientos, se identifica la visión de la arquitectura, y se consideran otros puntos, como el financiamiento y la aceptación por parte del involucrado.


6

2) Elaboración: 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) Construcción: Se construye software funcional, considerando las pruebas y el desarrollo como actividades en conjunto.

4) Transición: 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

Además de las cuatro fases de AUP, existen una serie de disciplinas desarrolladas de forma iterativa, las cuales en algunos casos pueden realizarse de forma simultánea, estas disciplinas son [URL 1, 2005]:

a) Modelado: Se intenta comprender el negocio de la organización, el problema del dominio y se identifican soluciones viables.

b) Implementación: Se lleva a código 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 detección de defectos, validaciones del sistema y verificaciones de requerimientos.

d) Despliegue: Se planifica la entrega del proyecto y la ejecución del plan con que se realizará dicha entrega.

e) Administración de la configuración: Se verifican versiones del trabajo, el control y la administración de cambios.

f) Administración 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 estén disponibles para cuando el equipo del proyecto las necesite.

Al igual que otras metodologías, 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.



7

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

1.5 Estructura del Documento

El presente documento se encuentra estructurado a través de diversos capítulos, cada uno de los cuales entrega información relativa a diversas temáticas en particular, pero siempre manteniendo una cohesión respecto al tema en el cual se está trabajado. A continuación se presenta un resumen de cada uno de los capítulos:

Capítulo 1 Descripción del Tema: Capítulo introductorio al tema, el cual considera aspectos como la metodología de trabajo a utilizar, la definición de objetivos y la planificación tentativa para cada una de las fases necesarias en el desarrollo del proyecto.

Capítulo 2 Agentes Inteligentes y Sistemas Multiagente: Se exponen los diferentes elementos que conforman la tecnología de agentes, desde el concepto de agente, hasta las diversas plataformas para su implementación.

Capítulo 3 Motores Gráficos 3D: Se presentan los motores gráficos utilizados para la creación de entornos 3D en tiempo real, además de las diversas técnicas que estos utilizan.

Capítulo 4 Modelado 3D: Se explican las diversas técnicas utilizadas para la creación de modelos 3D, los cuales finalmente formarán parte del entorno creado con el motor gráfico.

Capítulo 5 Selección de Sistema Multiagente: Se realiza una breve introducción a los Sistemas de Transporte Inteligente y los Sistemas de Transporte Flexibles. Además se explica el funcionamiento de la arquitectura MADARP, la cual es la base del sistema de transporte seleccionado para la creación del visualizador 3D. Finalmente se presenta el proyecto de magister realizado en [Baranlloni, 2009].

Capítulo 6 Desarrollo del Proyecto: Se presenta el caso de estudio en conjunto con la solución al problema. Además se realiza toda la fase de diseño, tanto del Sistema Multiagente como del motor gráfico.


Eliminado: Salto de página

8

Capítulo 7 Pruebas de Software: Se verifica que se estén cumpliendo de manera correcta los objetivos propuestos y también se valida todo el proceso que se lleva a cabo en el ciclo de vida de la aplicación.

Capítulo 8 Implementación: Se realiza un análisis en base al proceso de implementación llevado a cabo y sus resultados, así como también se presentan algunas de las técnicas empleadas en la interfaz 3D a fin de mejorar su resultado final.

Capítulo 9 Conclusiones: Por último, en este capítulo se realiza una comprensión general de los conceptos y se presentan las diversas conclusiones obtenidas a partir de la creación de este proyecto.

9

Capítulo 2: Agentes Inteligentes y Sistemas Multiagente

A lo largo de los años 70, los resultados obtenidos a partir de diversos estudios e investigaciones científicas en áreas tales como la inteligencia artificial, la informática distribuida, la ingeniería de software, las telecomunicaciones, entre otras., han dado origen a nuevas corrientes tecnológicas, como los Sistemas Multiagente, los cuales buscan solucionar problemas complejos mediante la comunicación y el razonamiento de forma cooperativa y distribuida. En este capítulo se presentará todo lo relacionado con la tecnología de Sistemas Multiagente, comenzando desde los conceptos más básicos 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 término de agente por parte de investigadores en este campo, algunas de las cuales se adecuan a la línea de investigación en la que trabajan o el problema el cual están desarrollando. Según 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 características propias de un agente de software, no son suficientes como elementos diferenciadores de otras entidades.

Una de las muchas definiciones para el término de agente es: “Toda entidad que puede percibir su entorno por medio de sensores y actuar contra este a través de efectores” [Rusell y Norvig, 1995]. En esta definición se pueden observar algunas características de un agente, las cuales son la capacidad de percibir y actuar en un entorno determinado (ver Figura 2.1).

10

Figura 2.1 Interacción agente/entorno [Salazar, 2003]

Otra definición de agente muy citada por investigadores es la de [Wooldridge, 1996], la cual dice: “Un agente es un sistema informático situado en un ambiente y que es capaz de realizar acciones de forma autónoma con el fin de conseguir sus objetivos de diseño”. En este caso se ha incorporado la capacidad de autonomía en el agente y también se ha acotado a un sistema informático con un objetivo determinado por el diseñador.

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. Según [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, otorgándole la existencia e influyendo tanto en su estado como en su comportamiento.

El entorno con el cual interactúa un agente se puede clasificar según 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 información del estado del entorno.

b) Determinístico v/s no determinístico: En un entorno determinístico, cualquier acción tiene un único efecto y este es garantizado.

c) Estático v/s dinámico: Un entorno estático 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 número finito de acciones y percepciones.



11

Cabe destacar, que a pesar que se han considerado las características más importantes de los agentes de software y los diferentes ambientes en que estos interactúan, actualmente no se ha logrado llegar a una definición concreta del término agente, esto debido a la ambigüedad que se produce al momento de crear un concepto que abarque todos los tipos de agente que existen, además de la gran cantidad de áreas en la que se puede aplicar esta tecnología.

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 años 50 se había centrado principalmente en el estudio de componentes de la inteligencia, tales como el razonamiento, la resolución de problemas, el aprendizaje, entre otros. Todo esto con el fin de crear sistemas computacionales capaces de pensar no numéricamente y así poder solucionar problemas de forma autónoma. A lo largo de los años 50 y 60 se realizaron diversos experimentos científicos sobre la inteligencia, obteniendo como resultado algunas técnicas para su representación computacional. Luego en los años 70 se crearon los Sistemas Expertos (SE) los cuales ya tenían algunas características 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 aceptación, la aparición de Internet, el comercio electrónico, la sociedad de la información, entre otros [Mas, 2005] y [Rusell y Norvig, 1995].

Un Agente Inteligente podría definirse como: “Una entidad de software que, basándose 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” [Hípola y Vargas-Quesada, 2005].

Según esta definición, un agente tiene la capacidad de adquirir conocimiento para así poder tomar decisiones más acertadas. El aprendizaje de un agente se puede adquirir de diferentes formas, algunas de las cuales pueden ser [Navarra y Martínez, 2006]:

• Observando e imitando el comportamiento del usuario.

• Recibiendo instrucciones explícitas del usuario.

• Observando a otros agentes.

• Pidiendo consejo a otros agentes.

Un agente podría determinarse inteligente si este posee además las siguientes características [Salazar, 2003]:

12

a) Racionalidad: Se basa en la adquisición de conocimientos de su entorno y aplicación de diversas reglas para determinar cómo 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 adaptación 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 característica deseable que debe tener un agente inteligente para satisfacer sus objetivos de diseño es la flexibilidad, la cual se puede dividir específicamente 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 Tipología de Agentes

Existen diversas clasificaciones para los agentes, las cuales dependen principalmente de la perspectiva en que se observen, como también de las características propias del sistema que se desea crear. A continuación se presentarán algunos tipos de agentes [Mas, 2005], [Hípola 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 información, ser autosuficientes, entre otros. Evitando además limitaciones como la falta de conocimiento para resolver un problema.

• Agentes móviles: Capacidad de moverse físicamente 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 información 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.



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 interacción con el usuario, liberándolo de tareas habituales, repetitivas y por lo general sencillas.

• Agentes de resolución de conflictos: Los agentes de resolución 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 solución. 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 interpretación y razonamiento.

b) Los conflictos externos surgen a partir de la interacción entre los agentes que componen el sistema.

• Agentes de búsqueda: En algunos entornos dinámicos como Internet la información se almacena de forma descentralizada, lo cual hace necesario utilizar herramientas que ayuden a su búsqueda. Los agentes de búsqueda se encargan de localizar, recuperar y almacenar la información 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 están destinados, no es suficiente para abarcar áreas demasiado grandes, esto se debe principalmente a las limitaciones que todavía existen al momento de integrar sistemas de agentes y la estructura en que se almacena la información actualmente [Hípola y Vargas-Quesada, 2005].

2.4 Sistemas Multiagente

La mayoría 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, construyéndose de esta forma sociedades de agentes que trabajan cooperativamente para encontrar una solución. De lo anterior se puede llegar a la siguiente definición: “Un Sistema Multiagente consiste en un número de agentes, los cuales interactúan unos con otros, típicamente intercambiando mensajes a través de una infraestructura de red computacional” [Wooldridge, 1996]. De este modo, el intercambio de información constituye el principal medio para que los agentes se puedan comunicar y entender entre sí.



14

En el caso más general, los Sistemas Multiagente actúan en representación de los usuarios, los cuales tienen objetivos y motivaciones muy diferentes. Por lo tanto, el éxito de la interacción de los agentes requiere que cada uno de estos tenga la capacidad de cooperar, coordinar y negociar con los demás agentes como también con los usuarios del sistema [Wooldridge, 1996].

Un Sistema Multiagente cooperante posee un conjunto de características, 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 común.

• Cada agente tiene un conocimiento e información incompleta respecto a la solución general del problema, realizando comportamientos de forma local.

• La información se encuentra descentralizada.

• No se posee un control del sistema global.

• Cada agente tiene un cierto grado de especialización en un área determinada del sistema.

De lo anterior se puede identificar la relevancia que tiene la distribución tanto de agentes como de las tareas que estos pueden realizar. La distribución permite fundamentalmente [Mas, 2005]:

• Mantener la autonomía de cada agente.

• Eliminar la necesidad de almacenar toda la información en un único agente.

• Descentralizar la toma de decisiones, generando de esta forma sistemas más robustos ante fallos.

• Realizar acciones coordinadas para la resolución de un problema.

• Adaptarse ante cambios, debido a la organización dinámica de la arquitectura de agentes.

2.5 Arquitecturas para la Construcción de Agentes

La arquitectura de un agente determina los mecanismos de interconexión de los módulos software/hardware que permiten que un agente pueda realizar determinadas conductas. A diferencia de otras tecnologías, como la orientación 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 módulos que interactúen entre sí para lograr la funcionalidad requerida, el método de descomposición es una forma de diferenciar algunos tipos de arquitectura [Salazar, 2003]. A continuación se presentan las arquitecturas más utilizadas, diferenciadas por el modelo de razonamiento que utilizan.

2.5.1 Deliberativas

Son aquellas arquitecturas que utilizan modelos de representación simbólica del conocimiento. Estos agentes comienzan de un estado inicial y mediante una serie de planes alcanzan sus objetivos. El sistema de planificación que debe poseer el agente se encarga de determinar los pasos que deben llevarse a cabo para lograr cumplir sus objetivos. Para la implementación de una arquitectura deliberativa, se debe encontrar una descripción simbólica 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 más estudiadas y extendidas actualmente, es la denominada arquitectura BDI (Belief, Desire, Intention), la cual puede observarse más claramente en la Figura 2.2. Esta se basa en la construcción de agentes racionales dotados de tres actitudes mentales: Creencias, Deseos e Intenciones. Las cuales pueden clasificarse en [Salazar, 2003]:

a) Actitudes de información: Están relacionadas con el conocimiento que un agente tiene sobre su entorno (creencias, conocimiento).

b) Pro-actitudes: aquellas que guían el comportamiento del agente (deseo, intención, obligación, elección, entre otros).

Desde un punto de vista informático, las creencias son la forma de representar el estado del entorno, almacenando eventos pasados y evitando de esta forma el tener que recalcular información previa. Además en entornos dinámicos es necesario el tener información pasada para poder adaptarse y evolucionar.

Los deseos u objetivos pueden ser simplemente un valor de una variable, como también una expresión simbólica de algo. Un objetivo representa algún estado final deseado, por lo que en conjunto con las creencias podrían por ejemplo recuperarse ante un fallo y tener un recuerdo de por qué ha comenzado su ejecución y cuál es su objetivo.


16

Figura 2.2 Arquitectura BDI [Mas, 2005]

El sistema necesita comprometerse con los planes y sub-objetivos, pero también ser capaz de reconsiderarlos en los momentos clave. Para esto es necesario tener un conjunto de caminos de ejecución o planes vinculados a la consecución de un objetivo, los cuales además pueden ser interrumpidos de una forma apropiada al recibir información 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 simbólico y por no utilizar razonamiento complejo, teniendo que utilizar únicamente la información actual para decidir su siguiente acción. En las arquitecturas reactivas se pueden aplicar diversos algoritmos, como por ejemplo el algoritmo de fusión, 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 fusión, en el cual un agente tiene dos acciones posibles: evitar obstáculos y seguir un objeto. Si el entorno requiere únicamente la acción de evitar obstáculos, se debe poder bloquear la otra automáticamente [Mas, 2005].

Un ejemplo de arquitectura reactiva es la propuesta por Roodney Brooks, conocida como arquitectura de subsunción [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 simbólico. En esta arquitectura se manejan jerarquías de tareas que definen un comportamiento (ver Figura 2.4). Suelen estar organizadas en jerarquías de capas, de menor a mayor nivel de abstracción [Brooks, 1991].

Figura 2.4 Arquitectura de subsunción [Brooks, 1985]

2.5.3 Híbridas

Debido a las limitaciones propias de las arquitecturas anteriores, se han planteado soluciones mediante arquitecturas híbridas, las cuales pretenden combinar aspectos de ambos modelos. Para esto se puede considerar como primera opción el construir un agente el cual este compuesto de dos subsistemas: uno deliberativo, el cual utilice un modelo simbólico 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 estructuración 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 acción de salida puede ser tratado solo por una de las capas.

Figura 2.5 Arquitecturas de agente por capas [Müller et al., 1995]

Al igual que en las arquitecturas de subsunción, las capas se organizan de forma jerárquica y con información del entorno a diferentes niveles de abstracción. La mayoría de las arquitecturas encuentran suficientes tres niveles [Mas, 2005]:

1) Reactivo, o de más bajo nivel: Las decisiones se toman a partir de los estímulos del entorno. Suelen estar implementados mediante arquitecturas de subsunción.

2) Conocimiento, o nivel intermedio: Centrado en el conocimiento que posee el agente sobre el medio, usualmente mediante una representación simbólica del conocimiento.





¶

19

3) Social: Se manejan aspectos sociales del entorno, como la comunicación entre agentes o los deseos e intenciones.

El comportamiento del agente se define mediante la interacción entre estos tres niveles, los cuales no necesariamente deben ser iguales para todas las arquitecturas.

2.6 Infraestructura de Agentes

Para hacer posible la interacción 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: ontologías, lenguajes de comunicación y protocolos de interacción.

2.6.1 Ontologías

Las ontologías se utilizan para especificar formalmente la información, entregando un significado común el cual permite que los agentes puedan entenderse. Más específicamente una ontología podría definirse como: “Un conjunto de aserciones que explican los conceptos involucrados en un dominio” [Castillo et al., 2010].

Una ontología se compone principalmente de seis elementos que permiten formalizar el conocimiento [Castillo et al., 2010]:

1) Clases: Ideas básicas las cuales se intentan formalizar.

2) Atributos: Estructura interna de las clases.

3) Relaciones: Interacción y enlace entre las clases.

4) Funciones: Tipo concreto de relación la cual identifica un elemento a partir del cálculo de una función considerando otros elementos de la ontología.

5) Instancias: Representación de objetos determinados de una clase los cuales no pueden ser divididos, ya que perderían su estructura y funcionalidades.

6) Axiomas: Teoremas declarados sobre las relaciones, que deben cumplir los diferentes elementos de la ontología.

2.6.2 Lenguajes de Comunicación para Agentes (ACL)

La capacidad de comunicar información es una de las cualidades más importantes que posee un agente, esta permite el intercambio y comprensión de mensajes, como también las


20

formas de comunicación (protocolos) entre agentes. Para llevar a cabo la comunicación es necesario que los agentes comprendan los siguientes tres aspectos:

1) Sintaxis: Estructura de los símbolos utilizados para comunicarse.

2) Semántica: Significado de los símbolos.

3) Pragmática: Interpretación de los símbolos.

La mayoría de las propuestas para la creación de un lenguaje de comunicación entre agentes se basan en la comunicación humana, particularmente en la teoría del acto del habla, la cual involucra tres aspectos [Austin, 1962]:

1) Locución: Emisión física desde el punto de vista del emisor.

2) Ilocución: Significado de lo que dice el emisor.

3) Perlocución: Acto que resulta de la locución.

Debido a las ambigüedades producidas en la ilocución de un mensaje, se utilizan diversos verbos performativos correspondientes a diferentes actos del habla, los cuales buscan darle una intención concreta al mensaje.

Existen varios estándares para la creación de lenguajes de comunicación entre agentes. A continuación se verán los dos más 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 información y conocimiento entre agentes. El lenguaje KQML puede dividirse en tres capas: la capa de contenido, la capa de comunicación y la capa de mensaje. La capa de contenido posee el contenido real del mensaje a transmitir. La capa de comunicación describe los parámetros de bajo nivel de comunicación, como la identidad del emisor y receptor, además de un identificar único asociado a la comunicación. Finalmente la capa de mensaje determina los tipos de interacciones que uno puede tener con un agente que también habla KQML, como también el lenguaje y la ontología 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 intención del mensaje.

2) Sender: Identificador del agente que envía el mensaje.

3) Content: Especifica el contenido del mensaje.

4) Receiver: Identificador del agente receptor del mensaje.




21

5) Language: Lenguaje utilizado en el contenido del mensaje.

6) Ontology: Especifica la ontología utilizada.

7) Reply-with: Identificador que debe ser utilizado en respuesta a este mensaje.

8) In-reply-to: Identificador del mensaje que provocó el envío de este mensaje.

2.6.2.2 FIPA ACL

FIPA ACL es un lenguaje de comunicación entre agentes propuesto por el estándar 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 también se basa en la teoría del acto del habla.

2.6.3 Protocolos de Interacción para Agentes (AIP)

Para establecer una comunicación entre agentes es necesario definir previamente el protocolo o acuerdo que van a seguir durante la conversación. Un protocolo es una descripción detallada del tipo y orden de los mensajes a utilizar, la cual considera además aspectos como las restricciones en el contenido de esos mensajes [Odell et al., 2003].

FIPA posee una lista de protocolos para la interacción entre agentes, los cuales son expresados mediante AUML (Agent Unified Model Language). AUML es un lenguaje de representación de protocolos mediante la adopción de UML. Para esto hace uso de una serie de herramientas de desarrollo ya existentes (CASE) orientándolas específicamente 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 más roles para cada agente involucrado.

b) Líneas de vida de agentes e hilos de iteración: La línea de vida de un agente define el periodo de tiempo en el cual un agente existe, comenzando su vida cuando este se crea y finalizándola cuando este se destruye. Por otra parte los hilos de iteración 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 más protocolos.


22

d) Semántica de mensajes: Se extiende la semántica de los mensajes UML con el fin de poder representar sin limitaciones la comunicación entre agentes.

e) Entrada y salida de parámetros por protocolos anidados: Los parámetros de entrada de los protocolos anidados son hilos de interacción que se llevan a cabo desde fuera del protocolo hacia adentro, mientras que los parámetros de salida son hilos de interacción que se inician desde dentro del protocolo anidado y se llevan hacia afuera.

f) Plantillas de protocolos: El propósito 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 acción.

• 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 acción cuando se cumpla una pre-condición.

• 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 realizarán 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 mediación 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 acción se cumple.

23

• Propose: Un agente iniciador propone la realización de una determinada tarea a un grupo de agentes, los cuales pueden aceptar o rechazar dicha propuesta.

2.7 Metodologías 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 metodologías que tienen como finalidad otorgar técnicas, herramientas y métodos para el desarrollo de agentes. A continuación se verán las metodologías de desarrollo de agentes más utilizadas:

2.7.1 MaSE

Multiagent Systems Engineering (MaSE), es una metodología de propósito general para el desarrollo de Sistemas Multiagente basados en los principios de la Ingeniería de Software, la tecnología orientada a objetos, entre otras [Wood y DeLoach, 2001]. MaSE divide el proceso de desarrollo en dos grandes fases: la fase de análisis y la fase de diseño, como puede observarse en la Figura 2.6.

La fase de análisis 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 creación del modelo de roles y la especificación del comportamiento de las tareas.

La fase de diseño considera cuatro etapas:

1) Crear las clases de agentes: Se determina la arquitectura total del Sistema Multiagente en términos de agentes y las conversaciones que estos realizan.

2) Construir conversaciones: El diseñador establece los protocolos de coordinación entre los agentes.

3) Ensamblar clases de agentes: Se crea la arquitectura interna de las clases de agentes.

4) Diseño del sistema: Se crean instancias de todas las clases de agentes en un agente real, esto mediante la utilización de un diagrama de implementación.



24

Figura 2.6 Etapas de desarrollo en MaSE [Wood y DeLoach, 2001]

2.7.2 GAIA

GAIA es una metodología de desarrollo que ha sido realizada específicamente para el análisis y diseño de sistemas basados en agentes. En particular, esta metodología alienta a los desarrolladores a construir sistemas basados en agentes con un diseño organizacional. Al igual que MaSE, esta se divide en la fase de análisis y la fase de diseño [Garro, 2012], modelo que puede verse más claramente en la Figura 2.7.


25

Figura 2.7 Modelo GAIA [Garro, 2012]

El objetivo de la fase de análisis es desarrollar una comprensión del sistema y su estructura, esta comprensión se obtiene a partir del sistema de organización. Una organización puede ser vista como una colección 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 análisis 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 interacción que exista entre los diferentes roles.

La fase de diseño 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 líneas de comunicación entre los diferentes agentes.

2.7.3 PASSI

PASSI (Process of Agent Societies Specification and Implementation) es una metodología paso a paso para el diseño y desarrollo de sociedades Multiagentes [Burrafato y Cossentino, 2002]. PASSI integra los modelos de diseño y conceptos de la Ingeniería de




26

Software Orientada a Objetos y los enfoques de la Inteligencia Artificial. Se utiliza UML como lenguaje de modelado, debido a su amplia aceptación y capacidad de extensión.

Figura 2.8 Modelos de la metodología PASSI [Burrafato y Cossentino, 2002]

El proceso de diseño de PASSI se compone de cinco modelos, los cuales pueden ser divididos en doce fases de construcción de Sistemas Multiagente. A continuación se describen cada uno de ellos [Burrafato y Cossentino, 2002]:

a) Modelo de Requerimientos del Sistema. Es una representación antropomórfica de los requisitos del sistema, se compone de cuatro pasos:

• Descripción del Dominio (D.D): Entrega como resultado una descripción funcional del sistema compuesto por una serie de diagramas de casos de uso convencionales.

• Identificación de Agentes (A.Id): Esta fase se obtiene a partir de los diagramas casos de uso de la D.D. Se crea una separación de las responsabilidades de cada agente del sistema mediante la utilización de paquetes UML.

• Identificación de Roles (R.Id): Identifica todos los caminos posibles en la comunicación entre agentes como también la comunicación inter-agente. Un camino describe un escenario de interacción que trabaja para lograr una tarea específica en el sistema. Esto se representa mediante la utilización de diagramas de secuencia.

• Especificación 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:

• Descripción de la Ontología (O.D): Se describe la sociedad de agentes teniendo en cuenta el punto de vista ontológico. Se hace uso de diagramas de clase para representar el conocimiento de los agentes y la pragmática de sus acciones.

• Descripción 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 también leyes de comportamiento.

• Descripción de Protocolos (P.D): Se utilizan diagramas de secuencia, generalmente en lenguaje AUML para especificar los protocolos utilizados en las comunicaciones en términos de performatives.

c) Modelo de Implementación de Agentes. Un modelo de la solución de la arquitectura en términos de clases y métodos, este se compone de dos pasos:

• Definición de Estructura de Agentes (A.S.D): Se hace uso de diagramas de clases para representar la estructura de la solución, tanto del Sistema Multiagente como de los agentes individuales.

• Descripción 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 representación de sus tareas).

d) Modelo de Código. Un modelo de la solución a nivel de requerimientos de código, este modelo produce los siguientes dos pasos :

• Reutilización de Código (C.R): En esta fase se intenta reutilizar patrones existentes de agentes y tareas. Considerando tanto patrones de código como también de diseño.

• Código Completo (C.C): En esta fase se realiza el trabajo clásico de un programador, el cual hace uso de los diferentes diagramas del diseño para completar el código de la aplicación.

28

e) Modelo de Despliegue. Modelo de la distribución de las partes de un sistema, este modelo se compone de un solo paso:

• Configuración de Despliegue (D.C): Se hace uso de diagramas de despliegue para representar la posición de los agentes en sistemas distribuidos o más generalmente en contextos de agentes móviles.

2.8 Plataformas de Desarrollo de Agentes

Se han creado muchas plataformas con el fin de facilitar el trabajo de interconexión y ejecución de los agentes en Sistemas Multiagente. Estas básicamente permiten a los desarrolladores abstraerse de ciertas rutinas y centrarse específicamente en los requerimientos del software más que en su implementación. A continuación se verá la plataforma JADE, principalmente por ser una de las más utilizadas en el desarrollo de agentes, además 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 través de un middleware que cumple con las especificaciones FIPA y una serie de herramientas gráficas que ayudan en las tareas de depuración e implementación del programa. El objetivo de JADE es simplificar el desarrollo de agentes y a su vez garantizar el cumplimiento del estándar FIPA. Para lograr este objetivo, JADE ofrece una gran una serie de características 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 número adicional de DFs conformes a las especificaciones FIPA para la creación de entornos multi-dominios, donde cada dominio es un conjunto lógico de agentes, cuyos servicios se anuncian a través de un DF común.

• Una API Java para el envío y recepción de mensajes ACL hacia o desde otros agentes.

• Un protocolo para la conexión 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 librería de IPs FIPA listos para ser utilizados.

• Soporte para la movilidad de agentes en computadores que posean la plataforma JADE.

• Librerías para administrar ontologías y lenguajes definidos por el usuario.

• Una interfaz gráfica para administrar muchos agentes y plataformas desde el mismo agente, facilitando todo el proceso de implementación y depuración.

Con formato: Sangría:Izquierda: 0,63 cm


30

Capítulo 3: Motores Gráficos 3D

3.1 ¿Qué es un Motor Gráfico?

Un motor gráfico es la pieza fundamental de las aplicaciones que trabajan con gráficos 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 gráfico visible por pantalla, sino que incorporan además una serie de otros módulos necesarios para otorgarle mayores capacidades y realismo a lo que se desea representar, como son: la reproducción de sonidos y videos, manejo de físicas, uso de dispositivos de entrada y salida, detección de colisiones, entre otros.

A pesar que la mayoría de los motores gráficos son utilizados para la creación de videojuegos, esto no impide que se puedan crear otro tipo de aplicaciones que requieran mostrar algo más que una interfaz de monitoreo al usuario.

3.2 APIs Gráficas

La mayor parte de los motores gráficos utilizan un conjunto de interfaces de programación de aplicaciones (APIs), las cuales básicamente 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]. Específicamente las APIs gráficas están destinadas únicamente al manejo de gráficos representados por pantalla, estas interfaces se encuentran limitadas a las capacidades de hardware que posea el computador en el que se está desarrollando la aplicación.

Existen dos tipos de APIs gráficas, las de propósito específico y las de propósito general. Las APIs de propósito específico se utilizan principalmente para la creación de aplicaciones destinadas a quienes deseen mostrar imágenes sin preocuparse del procedimiento necesario para producir dicha imagen, por otro lado, las APIs de propósito general están destinadas principalmente a programadores que necesiten hacer uso de funciones a un nivel de abstracción menor [Hearn y Baker, 2005].

A continuación se describirán las dos interfaces de programación gráfica más importantes que existen actualmente en el mercado: OpenGL y Direct3D.

31

3.2.1 OpenGL

El sistema gráfico OpenGL (Open Graphics Library) es una interfaz de software para hardware gráfico originalmente creada por Silicon Graphics Incorporated (SGI), esta permite la creación de programas interactivos que requieren mostrar gráficos 2D y 3D en tiempo real [Shreiner et al., 2008], [Maroto, 2005]. Algunas de las principales características que hacen de OpenGL una fuerte alternativa a considerar al momento de escoger una API gráfica 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 gráficas 3D, como son: los videojuegos, películas, simulaciones, hasta visualizaciones para uso científico, médico, comerciales, entre otros [Wright y Lipchak, 2004]. Actualmente es reconocido como estándar sobre gráficos computacionales, siendo además uno de los más utilizados en el mundo.

Ésta API posee una gran cantidad de funcionalidades, tales como el soporte de luces y sombras, mapeado de texturas, transparencia, animación de modelos, soporte de nieblas, texturas con profundidad, etc. [Wright et al., 2007].

Las partes que componen la escena gráfica en OpenGL son construidas a partir de primitivas geométricas básicas, como cubos, esferas, pirámides, etc., las cuales luego son convertidas mediante funciones matemáticas a un conjunto de pixeles (elemento visible más pequeño de una imagen). Finalmente estos pixeles se proyectan sobre un plano bidimensional, el cual puede ser por ejemplo el área de visualización 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 gráfico necesario para poder visualizar imágenes 3D por pantalla. Una de las características de esta API, es que trabaja directamente con el hardware gráfico, a diferencia de otras interfaces de dispositivos gráficos, aumentando de esta forma el rendimiento considerablemente [Thomson, 2006].

Además esta API fue diseñada para tener fácil acceso a las características avanzadas 3D del hardware gráfico, creando una capa de abstracción 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 ejecución.

3.3 Representación Tridimensional de Geometrías

En 3D, las superficies están construidas a partir de un conjunto de polígonos, los cuales son creados y unidos entre sí. La unión de cada uno de estos polígonos conforman la superficie de una figura, a la cual se le denomina modelo 3D [Hess, 2010].

Figura 3.1 Elementos básicos de una geometría [Elab. Propia]

Toda geometría de un modelo 3D se compone básicamente de tres elementos (Figura 3.1), los cuales son [Ezequiel, 2004]:

• Polígonos: Conforman la superficie a representar. Todos los polígonos en los modelos 3D deben ser cóncavos, es decir, cada uno de sus ángulos interiores debe ser menor a 180°.

• Aristas: Segmentos o lados de un polígono, estos unen dos vértices consecutivos del modelo.

• Vértices: Puntos extremos de las aristas, estos poseen diferentes tipos de información, los cuales pueden ser:

• Un identificador: Para localizar y diferenciar el vértice de los demás vértices en el entorno.

• Posición en el mundo 3D: Representado mediante coordenadas (x, y, z).

• Coordenadas de textura: Utilizadas para ubicar correctamente una imagen de textura en la geometría del modelo.

• Un vector normal: Perpendicular al plano que forma el polígono, utilizado para determinar tanto la dirección del vector, como la del polígono.


33

• Color e información de iluminación: Necesario para generar los cálculos de transformación, iluminación y color.

• Parámetros de Skinning: Para crear una relación entre el vértice y los huesos del modelo, necesario para crear las animaciones del objeto.

Las GPU (Graphics Processing Unit) que poseen las tarjetas gráficas, se han especializado en operaciones sobre triángulos, por lo cual es necesario en muchas ocasiones convertir los modelos 3D formados por polígonos con una cantidad mayor a tres vértices a modelos conformados únicamente por polígonos de tres vértices, proceso que por lo general es realizado por el motor gráfico o la herramienta de modelado que se está utilizando, siendo totalmente transparente para el diseñador.

Se debe considerar que el trabajar con superficies triangulares no impide el diseñar figuras con una calidad superior, ya que todos los polígonos pueden reducirse hasta su representación mínima (3 vértices), como puede ser el cuadrado, compuesto por dos triángulos (ver Figura 3.2 (a)), o figuras más complejas, mediante la utilización de vértices en común para la creación de superficies triangulares (ver Figura 3.2 (b))

Figura 3.2 Ejemplo polígonos con triángulos [Ezequiel, 2004]

En muchas ocasiones, se utiliza un conjunto de primitivas geométricas básicas 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 básicas más conocidas.



34

Figura 3.3 Primitivas geométricas básicas [Elab. Propia]

3.4 Técnicas Utilizadas por Motores Gráficos 3D

El realismo del entorno en las aplicaciones es un factor clave para la aceptación por parte de los usuarios, creándoles la sensación 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 cálculos y tiempo de procesamiento necesario por parte de las tarjetas gráficas para generar la imagen final, teniendo como resultado un decremento en la fluidez y movimiento de la escena, además de la perdida de atención por parte de los usuarios. Los motores gráficos utilizan una serie de técnicas que buscan aumentar el realismo, pero sin perder de vista el rendimiento y la fluidez de la escena. A continuación se verán algunas de las técnicas utilizadas, las cuales en su mayoría 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 gráficos 3D, el proceso de renderizado se realiza en el pre-renderizado o en tiempo real. El pre-renderizado es un proceso intensivo que es típicamente utilizado en las películas, mientras que el renderizado en tiempo real, es utilizado en el desarrollo de videojuegos basados en el uso de tarjetas gráficas [Gregory, 2009].

3.4.2 VSync

La sincronización vertical (VSync), es una función que sirve para sincronizar el número de frames generados por la tarjeta gráfica con la tasa de refresco de la pantalla. Esto previene la aparición de defectos visuales, como la desaparición de elementos en la escena, parpadeos, movimientos bruscos, entre otros. Este problema surge debido a que generalmente las tarjetas


35

gráficas son capaces de generar una gran cantidad de imágenes por segundo, superando considerablemente la cantidad aceptada por parte de los monitores.

Figura 3.4 Ejemplo de error en sincronización de frames [URL 3, 2012]

3.4.3 Árboles BSP

La partición binaria del espacio (BSP) es un método para subdividir recursivamente el espacio en elementos convexos utilizando planos. Esta subdivisión permite representar la escena mediante la estructuración de datos en un árbol, conocido como árbol BSP. Una de las funcionalidades de esta estructuración, es la organización de los polígonos del modelo de forma jerárquica respecto a representación de las posiciones en el espacio [Gómez et al., 1999]. En la Figura 3.5 se puede observar como a partir de un polígono se va generando el árbol BSP, subdividiendo la superficie poco a poco mediante planos, obteniendo como resultado polígonos cóncavos.

Figura 3.5 Ejemplo árbol BSP [URL 4, 2011]

3.4.4 Antialiasing

El aliasing, es el efecto de “dentado” producido al generar líneas en ángulos cercanos a líneas verticales u horizontales. Estas irregularidades son causadas por la cuadrícula de pixeles que utilizan las pantallas, en las cuales se almacenan los pixeles de forma exacta. La técnica



36

denominada antialiasing, busca reducir o eliminar esta distorsión, 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 técnicas para implementar el Antialiasing en los motores gráficos, las cuales varían en calidad y rendimiento. Algunas de ellas se basan en transformar la imagen a una resolución mayor, para luego mostrarla en una resolución menor, proceso que requiere un gran esfuerzo de procesamiento gráfico. Otra forma es difuminar los bordes de las líneas para así engañar el ojo humano, dando la sensación de suavizado, como puede observarse en la Figura 3.6. Actualmente existen técnicas mucho más 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 imágenes [Ezequiel, 2004].

3.4.5 Iluminación y Transformación (T&L)

La transformación, consiste en la conversión de coordenadas en el espacio. Esta puede ser utilizada para el movimiento de los diferentes objetos 3D de la escena, como también para la conversión de coordenadas 3D a las coordenadas 2D de la pantalla (ver Figura 3.7).


37

Figura 3.7 Proceso de transformación de coordenadas 3D a 2D [URL 5, 2000]

Por otra parte, la iluminación 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 iluminación difusa y la iluminación especular. La iluminación difusa es aquella que incide sobre un objeto y se dispersa de igual forma en todas las direcciones, sin depender de la posición en que se encuentre el espectador, ni la dirección de la luz; un ejemplo de este tipo de luz es sol. La iluminación especular, por el contrario, depende de la posición del espectador, la dirección de la luz y la forma de la geometría 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 cálculos y procesamiento que se requiere para realizar tanto la iluminación, como la transformación en una escena, se utiliza hardware especializado para los cálculos, específicamente 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. Además de aumentar el realismo en la escena, las sombras también ayudan a la comprensión del entorno por parte del espectador, el cual capta mucha información 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 implementación de las sombras, han surgido una serie de técnicas, cada una con sus ventajas y desventajas. Una de las técnicas más 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 polígonos, 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 más simples de geometría para elementos que no tienen una gran relevancia visual en determinados momentos, por ejemplo, geometrías que se encuentran muy lejos de la visión 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, además existe Cg, el lenguaje de Shader de Nvidia. Estos lenguajes trabajan mediante la utilización de tres elementos: Vertex Shaders, Geometry Shaders y Pixel Shaders [Engel et al., 2008]:

a) Los Vertex Shaders, son herramientas para la modificación de los vértices de un modelo, realizando sobre estos, operaciones matemáticas para definir colores, luces y texturas. Además, con los Vertex Shaders se pueden realizar transformaciones a la geometría del modelo, obteniendo como resultado en algunos casos animaciones complejas, efectos de onda, generación de niebla, entre otros.

b) Los Geometry Shaders, son técnicas para la creación de nuevas primitivas, por ejemplo: puntos, líneas o triángulos. Estos se aplican luego de la utilización de los Vertex Shaders.

c) Los Pixel Shaders, son utilizados para trabajar con los pixeles de las imágenes generadas al final del proceso de renderizado, estos se aplican luego de los Geometry Shaders y los Vertex Shaders.

3.4.9 Radiosity

Esta técnica se utiliza para el cálculo de iluminación global en ambientes cerrados. La radiosidad busca resolver las interacciones de las luces que se producen en la escena, además de encontrar un equilibrio entre la energía producida por los objetos emisores de luz y la energía absorbida por los objetos en el entorno [Rodríguez et al., 2003]. La radiosidad




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 polígonos que no se encuentran necesariamente en su dirección, esto debido principalmente a la capacidad de absorción y reflexión de las demás superficies que componen la escena.

Figura 3.11 Ejemplo de radiosidad [URL 7, 2012]

3.5 Listado de Motores Gráficos 3D

A continuación se describirán algunos de los motores gráficos más utilizados para la implementación de entornos en 3D en tiempo real:

• Irrlicht Engine :

Irrlicht es un motor de videojuegos de código abierto desarrollado por Nikolaus Gebhardt. Este motor utiliza las APIs gráficas Direct3D, OpenGL y el software de render Irrlicht para la generación de entornos de alto rendimiento en tiempo real [URL 8, 2012].

Algunas de las características destacables de este motor son: su independencia de la plataforma, la utilización de Shaders GLSL y HLSL, animación de personajes, una gran cantidad de formatos soportados, utilización de z-buffer, LODs, generación de efectos especiales mediante partículas, 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 código abierto y libre, bajo la licencia BSD [URL 9, 2012]. El lenguaje de programación para el cual fue destinado Panda3D es Python, aunque también se encuentra una versión disponible para C++. Las APIs gráficas utilizadas por este motor son OpenGL y Direct3D.


41

Algunas características del motor son: implementación de una GUI propia, soporte para inteligencia artificial (PandaAI), herramientas de depuración, efectos de partículas, soporte de físicas 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, además de funcionar en las plataformas Windows, Linux y Mac OS X.

Algunas de las características más destacables de este motor, son su amplia comunidad, su gran cantidad de documentación, 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 código abierto licenciado bajo LGPL. Crystal Space funciona en las plataformas Windows, GNU/Linux y Mac OS X. Algunas características son: lenguaje de Shaders Cg, BSP, un administrador de la escena (objetos organizados jerárquicamente), soporte de animación y sonidos, Light Maps, soporte para dispositivos de I/O, LODs, entre otros.

• Unity 3D:

Unity es un motor gráfico 3D en tiempo real, específicamente dedicado a la creación 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 características, como la capacidad de crear aplicaciones en red, el soporte de físicas de PhysX de Nvidia, reproducción de sonidos y música, LODs, Light Mapping, algoritmos para el seguimiento de rutas (Path Finding), un generador de terrenos, un set de herramientas de depuración y programación, 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 gráfico 3D para computador y consolas bajo licencia libre, desarrollado por la compañía 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 gráficas 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 creación de animaciones faciales realistas a partir de sonidos; el Speed Tree Foliage Editor, para la creación de árboles animados en tiempo real; el UnrealScript, un lenguaje de scripting para la programación de los juegos en Unreal, entre muchas otras. Algunas de las características de este motor son: renderizado en sectores, árboles BSP, LODs, detección de colisiones, Light Maps, Shaders, Radiosidad, entre otros.

• jMonkeyEngine:

Java Monkey Engine (jME), es un motor gráfico libre, bajo licencia BSD, orientado al desarrollo de aplicaciones en 3D [URL 14, 2012]. jME es actualmente uno de los motores más completos escritos en Java, con una gran cantidad de colaboradores y una completa documentación. La API gráfica utilizada por este motor es OpenGL, pero debido a su capa de abstracción, permite que cualquier API de renderizado pueda incorporarse como un plugin. LWJGL y JOGL ya están incorporadas.

jME se basa en una arquitectura de escenas, las cuales se estructuran como un árbol, es decir, se almacena la información en nodos, los cuales pueden tener cualquier cantidad de nodos hijos, pero cada hijo puede tener solo un padre. Esto permite un recorrido mucho más sencillo y rápido de la información, descartando de esta forma algunas ramas que son innecesarias. La geometría final de la escena 3D se encuentra ubicada en los nodos hojas (nodos extremos del árbol).

Este motor gráfico posee un complejo kit de desarrollo de software (SDK) para facilitar la tarea de desarrollo y depuración. Una de las herramientas disponibles en este kit, es la sólida plataforma de desarrollo denominada jMonkeyPlatform, la cual entrega una interfaz de alto nivel basada en el conocido IDE Netbeans de Oracle. Otra de las características del SDK, es la estructuración de cada uno de los elementos que conforman la escena mediante assets, los cuales pueden ser instanciados fácilmente en la fase de programación.

Capítulo 4: Modelado 3D

4.1 Técnicas de Modelado

Actualmente existe una amplia gama de posibilidades a la hora de escoger una técnica de modelado, la mejor técnica depende muchas veces de lo que se desea realizar. Cabe

43

destacar, que las diversas técnicas de modelado pueden utilizarse en conjunto para la creación de un solo modelo 3D. A continuación se mostrarán algunas técnicas para la creación de modelos 3D.

4.1.1 Modelado Poligonal

Esta es una de las técnicas más utilizada, principalmente por su rapidez y simplicidad a la hora de crear diversos tipos de superficie. El modelado poligonal consiste en la modificación directa de los vértices, aristas y polígonos de cualquier tipo de geometría. La más conocida de esta técnica es el Box Modeling, o modelado de caja, técnica que consiste en la creación del modelo comenzando con una caja como base. En la Figura 4.1 se puede observar cómo crear un pie a partir del desplazamiento de los vértices y la aplicación de algunas transformaciones en los polígonos.

Figura 4.1 Ejemplo box modeling [URL 15, 2006]

Esta técnica resulta ideal para la creación de modelos que poseen una estructura rígida 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 técnica es que se debe decidir la resolución que se le dará a la superficie con antelación, si más adelante se necesita aumentar la cantidad de polígonos será mucho más complicado.

4.1.2 Modelado mediante Splines

El modelado mediante splines o también llamado NURBS Modeling, consiste en la creación de modelos 3D a partir del uso de líneas 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,Inglés (Estados Unidos)

44

Figura 4.2 Ejemplo NURBS modeling [URL 16, 2004]

Esta técnica, a diferencia del Box Modeling, es mucho más adecuada para la creación de superficies orgánicas, 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 conexión y ubicación de las diferentes líneas vectoriales que compondrán el modelo, mientras más complejo y curvo sea el modelo, mayor será la cantidad de splines que se necesiten. En la Figura 4.3 se puede observar más claramente el perfil utilizado para la creación de una superficie.

Figura 4.3 Utilización de un perfil [URL 17, 2011]

4.1.3 Digital Sculpting

Hace algunos años atrás, algunas aplicaciones para la creación de modelos 3D solían 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 sensación de estar trabajando directamente con arcilla [Keller, 2011].



45

Esta técnica de modelado básicamente trabaja con mallas de muy alta resolución a la que se le aplican distintos tipos de herramientas para ir dándole forma. En algunos casos los diseñadores deben realizar modelos 3D profesionales pero manteniendo una baja cantidad de polígonos (Low Poly), una alternativa para lograr este requerimiento es crear el modelo mediante la técnica de sculpting, la cual posteriormente se convierte en un mapa de normales y se asigna al modelo en baja poligonización, aproximando de esta forma la gran cantidad de detalles que poseía 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 moldeándolo y aumentando la cantidad de polígonos. A diferencia de otras técnicas de modelado, en el sculpting se puede comenzar a trabajar a partir de un modelo que ya se encuentra en alta poligonización, 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, función matemática 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 comúnmente como mapeado de textura.


46

Figura 4.5 Ejemplo mapeado de textura [URL 19, 2008]

Además hay que considerar que el texturizado es una de las fases más 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 personalización y realismo.

4.2.1 Técnicas de Texturizado

Existen muchas formas para texturizar una superficie, a continuación se detallarán algunas de ellas.

4.2.1.1 Procedurales

Generadas mediante fórmulas matemáticas, buscan crear representaciones reales de elementos como: nubes, madera, metales, piedras, etc. Estas texturas pueden crearse a partir de dos tipos de mapas: mapas geométricos o mapas aleatorios. Los mapas geométricos poseen un patrón bien definido, por lo que no tienen aleatoriedad, mientras que los mapas aleatorios son impredecibles, pero suelen seguir un patrón regular (ver Figura 4.6).

Figura 4.6 Ejemplo texturas procedurales [URL 20, 2009]



47

A continuación se describen algunas ventajas y desventajas de la utilización de texturas procedurales [URL 20 2009]:

• Son densas: Esto quiere decir que no se pierde nitidez al aumentar la cercanía de esta a la cámara.

• Son infinitas: Debido a que se definen para todo el espacio, lo cual es muy útil cuando se debe texturizar modelos con un tamaño elevado.

• Ocupan poco espacio: Ya que no se almacenan en el disco como las imágenes.

• Difíciles de crear: Debido a que estas no se dibujan, sino que se crean mediante algoritmos matemáticos.

• 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 manipulación directa del color en los vértices [URL 21, 2012].

Figura 4.7 Ejemplo de vertex paint [URL 22 2009]

Actualmente existen diversas herramientas que implementan esta técnica, esto lo realizan mediante la utilización de diversos pinceles, a los cuales se les pueden añadir diferentes propiedades, como rugosidad, opacidad, tamaño, color, intensidad, etc. En la Figura 4.7 se puede observar la utilización de esta técnica aplicada directamente a una superficie.

4.2.1.3 Texturizado por Imagen


48

Como su nombre lo indica, esta técnica se basa en la utilización de imágenes para generar la textura de un modelo 3D. Debido a que el tamaño de la textura influye directamente en el rendimiento que tendrá posteriormente la aplicación, es necesario que esta tenga un tamaño lo más pequeño posible, considerando una proporcionalidad con el número de pixeles que se ocupará en la escena. Para el uso de memoria más 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 más utilizadas es el UV Mapping. Esta técnica consiste en la asignación de pixeles de la imagen 2D a la superficie del polígono 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 vértices de la malla, si luego el modelo quiere pasarse a un motor gráfico, es necesario que la geometría 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 continuación se describirán algunos de los softwares más utilizados para la creación de modelos 3D:

• 3D Studio Max:

3D Studio Max es un programa de modelado, animación y renderización en 3D desarrollado por Autodesk [URL 24, 2012]. La utilización de 3D Studio Max permite al usuario la fácil visualización y representación de los modelos en una intuitiva interfaz, así


49

como su exportación 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, diseñadores de gráficos de movimiento, arquitectos, ingenieros, etc. 3D Studio Max es una de las herramientas más utilizadas profesionalmente, debido a su larga trayectoria y potentes capacidades, además de ser compatible con una gran cantidad de software externos.

• Maya:

Maya es un software de modelado 3D destinado principalmente a la animación cinematográfica [URL 25, 2012]. Al igual que 3D Studio Max, su actual desarrollador es Autodesk. Maya se caracteriza por su potencia, posibilidades de expansión, personalización y herramientas, además este software posee el MEL (Maya Embedded Language), código núcleo de Maya, con el cual se pueden crear diversos scripts y personalizaciones del software. Este software otorga herramientas para animación, modelado, simulación, renderizado, técnicas de movimiento, y composición.

• Google SketchUp:

Este software permite la creación de modelos 3D mediante herramientas intuitivas y fáciles 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 galería disponible en Google [URL 26, 2012].

A diferencia de otros programas de modelado 3D, en SketchUp, todos los modelos 3D están formados únicamente de dos elementos: aristas y polígonos. Además existen herramientas como el “empujar/tirar” , el cual permite extruir superficies planas a formas tridimensionales. Algunas características de este software son: coloreado directo en la superficie, dividir el modelo en secciones (para verlo por dentro), utilización de capas para ordenar las figuras, intercambio de información con Google Earth (debido a que pertenecen a la misma familia), entre otros.

• Cinema4D:

Desarrollado por Maxon, Cinema4D es un software de creación de gráficos y animación 3D de nivel profesional [URL 27, 2012]. Algunas características de este software son: implementación de materiales y texturas clásicas y avanzadas, herramientas de animación, permite importar y exportar a una gran variedad de formatos de archivo para integrar con muchos otros software, gran cantidad de posibilidades de iluminación 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 más fácilmente; y una curva de aprendizaje bastante alta (en comparación con otros tipos de software para la creación 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 aplicación de arte experimental con una tecnología ú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 difíciles de realizar en los programas convencionales de modelado, debido a su arquitectura orientada a la implementación de técnicas de modelado poligonal.

Un flujo de trabajo típico, es el crear la base de la geometría 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 código abierto. Actualmente es desarrollado por la Fundación Blender bajo licencia GPL [URL 29, 2012]. Este software ofrece un amplio espectro de modelado, animación, texturizado y video post-processing, todo esto en un solo paquete. Algunas características claves de este software son [Hess, 2010]:

• Una suite de creación totalmente integrada, la cual otorga una amplia gama de herramientas esenciales para la creación de modelos 3D, entre las que destacan son: la creación de modelos mediante técnicas de modelado convencionales, soporte para Digital Sculpting, texturizado mediante Vertex Paint, entre otros.

• Peculiar interfaz gráfica, la cual es completamente flexible y adaptable a los diferentes requerimientos del usuario.

• Multiplataforma, debido a su interfaz gráfica basada en OpenGL.

• Gran calidad, rápida creación y eficiente flujo de trabajo.

• Gran cantidad de usuarios que utilizan este software.

• Tamaño ejecutable bastante reducido y de fácil distribución.

• Soporte para la creación de videojuegos mediante el lenguaje de programación Python.

Actualmente, Blender es compatible con las plataformas Windows, Mac OS X, Linux, Solaris, FreeBSD e IRIX.

51

Capítulo 5: Selección de Sistema Multiagente

Para la integración 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, específicamente el Dynamic Dial-a-Ride Problem (D-DARP) utilizado en [Donoso y Sandoval, 2009]. A continuación se explicará en qué consisten estos sistemas.

5.1 Sistemas de Transporte Inteligente

En la actualidad, la función de los organismos oficiales y departamentos de transporte ha evolucionado de manera importante; la labor de estas agencias se ha expandido, más allá de las tareas de construcción y mantenimiento de la infraestructura necesaria para el transporte, a encargarse también de la operación 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 congestión, seguridad vial, ineficiencia y pérdida de productividad que posee la movilidad. El incumplimiento de los horarios en el transporte público, el incremento de los tiempos de viaje, la contaminación ambiental y acústica, y los elevados costos del servicio son algunos de estos problemas. Todo esto produce una disminución en el bienestar de la población, además de importantes pérdidas económicas.

Con el fin de manejar las redes de transporte de manera eficiente, la atención de las mismas se ha convertido en un foco principal, surgiendo de esta forma diversos sistemas informáticos. Los Sistemas de Transporte Inteligente (ITS), están siendo un eficiente apoyo en la disminución de problemas de transportes urbanos e interurbanos, no solo mejorando la movilidad, sino haciéndola mucho más sostenible. Estos pueden describirse como la unión entre los avances en las tecnologías de información y las comunicaciones (TICs), las cuales han revolucionado el ámbito del transporte, permitiendo incluso realizar algunos servicios que hasta ahora habían sido impracticables.

La base de los ITS está formada por la adquisición de datos de diferentes dispositivos (estaciones remotas, radares, detectores infrarrojos, análisis de imágenes, etc.), los cuales son procesados por diferentes computadores para la elaboración de información, la cual una vez integrada, se ofrece al usuario para ayudarlo en la toma de decisiones. Algunas aplicaciones típicas de los ITS son las cámaras de video para detectar accidentes, tableros de mensajes dinámicos de información, detectores de vehículos para calcular tiempos de recorrido, sistemas de pago electrónico, centros de gestión de tránsito, sistemas inteligentes de semáforos, sistemas de interacción 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 gestión de tráfico, se mejoren las comunicaciones o se incremente la tecnología utilizada por los diferentes tipos de transporte, siempre queda, lo que en definitiva, puede mejorar o empeorar la situación: 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 rígidas (tradicional transporte público local); o bien un transporte con un costo mucho más 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 público tradicional y el taxi, el cual sería competitivo para una amplia gama de demandas de movilidad [Picco, 2009].

La urbanización ha provocado además un fuerte aumento en los trayectos, tanto de las afueras de la ciudad, como también de las poblaciones locales. Esto se debe principalmente al incremento del poder adquisitivo de cada una de las personas, como también a la necesidad de rutas especiales que se adapten de mejor forma a sus requerimientos personales.

La economía actual, cada vez más orientada al servicio, fomenta el que la mayoría 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 más extendida, sino que también 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 utilización de los servicios de transporte público 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 vehículos 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 público avanzada, orientada al usuario y caracterizada por la realización de trayectos flexibles y la programación de vehículos 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 gestión de la movilidad destinada a áreas de baja densidad de población o áreas con períodos de baja demanda de desplazamientos. Es un sistema eficiente y está orientado hacia el usuario del transporte público, todo esto para hacer frente a las cambiantes necesidades de movilidad. Las rutas,

Eliminado:

53

tiempos de salida, los vehículos 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 dinámicas (alternativas), y programando los vehículos, junto con las operaciones de información 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 también suplir la demanda de transporte en épocas de baja demanda, como la producida en días feriados, fines de semana o en las noches [Cubillos, 2005].

Para llevar a cabo la implementación y manejo de este tipo de servicios, es fundamental que los usuarios cuenten con instrumentos amigables y además que la organización encargada de los servicios sea capaz de manejar el conjunto de recursos de transporte que están involucrados. Para esto, es necesario que la arquitectura de los sistemas de respuesta a demanda cuenten con la adecuada tecnología de comunicaciones y herramientas tecnológicas [Cubillos, 2005].

5.3 Dial-a-Ride Problem

Los sistemas de transporte de respuesta a demanda, desde el punto de vista de la investigación de operaciones y de las matemáticas, corresponden a un problema conocido como Dial-a-Ride Problem (DARP). El DARP consiste en el diseño de rutas de vehículos y horarios para usuarios, los cuales especifican solicitudes de transporte desde un punto de origen (punto de recolección) a un punto de destino (punto de entrega). En la versión estándar, el transporte es suministrado mediante una flota de vehículos idénticos basados en la misma estación.

El objetivo es planificar un conjunto de rutas de vehículos de costo mínimo con capacidad de acomodar tantas solicitudes como les sea posible, considerando además 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 solución planteada de problema, mientras que restricciones como el uso compartido o exclusivo del transporte o habilitación 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 vehículos, 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 reducción de las molestias del usuario debe ser equilibrada con la

54

minimización de costos de operación. Además, la capacidad del vehículo constituye una restricción en el DARP, no así en problemas de PDVRP, particularmente los relacionados con la recepción y entrega de cartas o paquetes pequeños [Cordeau y Laporte, 2002].

Los servicios del Dial-a-Ride pueden operar de un modo estático o dinámico. 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 día y las rutas de los vehículos se ajustan en tiempo real, satisfaciendo de esta forma la demanda generada.

La mayoría de los estudios del DARP asumen una flota homogénea de vehículos basadas en una sola estación. Si bien, en la mayoría de los casos, esta hipótesis refleja la realidad, es importante tener en cuenta que pueden existir otro tipo de situaciones en la práctica, es decir, la existencia de varias estaciones, como también flotas heterogéneas. En las flotas heterogéneas, pueden surgir situaciones como: algunos vehículos pueden estar diseñados solo para el transporte de sillas de ruedas, otros únicamente para el transporte de pasajeros ambulatorios, y algunos diseñados para ambos casos [Cordeau y Laporte, 2002].

La principal consideración de algunos problemas, es el determinar el tamaño y composición 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 tamaño fijo. De lo anterior, se pueden considerar dos problemas: el primero es minimizar los costos sujetos a la satisfacción total de la demanda; y el segundo es maximizar la satisfacción de la demanda sujeta a la disponibilidad de vehículos. 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 planificación y programación de pedidos de transporte de pasajeros en un ambiente dinámico. MADARP es parte de un modelo de capas que permite la implementación de diferentes tipos de sistemas de transporte de pasajeros. Esta arquitectura proporciona un sistema base constituido por agentes, los cuales realizan la interfaz básica, el planeamiento y los servicios de soporte para manejar los diversos tipos de peticiones de transporte, utilizando una flota heterogénea de vehículos. Mediante la extensión e implementación de la base de agentes proveída 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, además del nivel de abstracción que estos poseen. A continuación se realizará una breve descripción de cada una de estas capas:

a) Capa de interfaz: Permite la conexión entre el mundo real y el sistema de transporte, proporcionando agentes capaces de conectarse con los actores del sistema (operadores de los vehículos y pasajeros del transporte).

b) Capa de planeamiento: Contiene agentes dedicados al procesamiento y planeamiento de los viajes de cada uno de los vehículos 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 ontología: Proporciona un medio de integración y cooperación 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, distribuyéndose entre las diferentes capas del sistema. De forma general, los agentes de interfaz proporcionan la entrada y la señal monitoreada, para que luego los agentes de planeamiento puedan determinar la planificación de los vehículos involucrados. Los agentes de servicio apoyan todos estos



56

procedimientos, proveyendo la información requerida para el proceso de replanificación (debido a que es dinámico), y la ontología 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 vehículos, los clientes y la empresa de transporte, cada uno de los cuales se encuentra modelado en términos de agentes. En la metodología MADARP, cada vehículo está representado mediante un agente Vehículo 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, considerándose 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 planificación y control del servicio de transporte de pasajeros proporcionado.

En el caso de los vehículos, los agentes que lo conforman proporcionan la interoperabilidad entre el actor y el sistema de transporte al cual pertenece. El agente Vehículo provee principalmente dos funcionalidades: la primera es entregar información relativa a cambios en la planificación original, como un nuevo cliente por transportar, una cancelación de transporte, cambios en las condiciones del tráfico, etc. La segunda funcionalidad es otorgarle al conductor un canal de comunicación durante su jornada acerca de cualquier contingencia que pueda presentarse. El agente Schedule está encargado de manejar la ruta del vehículo y procesar cualquier nuevo pedido de transporte de un cliente.

En el caso de los clientes, los agentes que lo conforman proporcionan la interacción 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 también a las preferencias sobre situaciones de contingencia, por ejemplo, atrasos, congestión 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. Además existe un sistema entero de agentes que colaboran para dar soporte a las diferentes funciones requeridas, por ejemplo, el concordar las peticiones con los vehículos, 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 realización de una interfaz 3D para un sistema de transporte de pasajeros basado en la arquitectura MADARP.

Manager3D Schedule

Map

SchedGen

TripGen

Broker

EventClient

TripRequestPlanner

EventVehicle

CrearMapa

GestionarMapa

<<include>>

GestionarPropuestas

ProcesarSolicitudes

GestionarEventos

<<include>><<c>>

GenerarAgentesSchedule

GenerarFlota

Vehiculos<<include>>

ObtenerPerfilCliente

GenerarEventos

Trip-Request

GenerarSolicitudde Viaje

<<include>>

<<include>>

GestionarSuscripciones

GenerarMatchingVehiculos<<include>>

ObtenerEventosClientes

MostrarEventosClientes

GenerarEventosClientes

<<include>>

<<include>>

GestionarItinerariosVehiculos

Procesar EventosExternosVehiculos

ProcesarEventosVehiculos

GenerarPropuestas

<<include>>MostrarEventosVehiculos

<<include>>

<<c>><<c>>

<<c>> <<c>>

<<c>>

<<c>>

<<c>>

<<c>>

NegociarPropuestas

ProcesarEventosExternosCliente

ProcesarEventosCliente

GestionarSolicitudesCliente

<<c>>

<<c>>

<<c>>

GenerarEventosVehiculos

ObtenerEventosVehiculos

<<include>>

<<include>>

<<c>>

<<c>><<c>>

<<include>>

<<include>>

<<include>>

<<c>>

<<c>>

GenerarMapa 3D

GestionarMotor 3D

<<include>>

ProcesarVisualizacionEventos

GestionarDatos

<<include>>

<<c>>

<<c>>

<<c>>

Monitor

<<c>>

Figura 5.2 Identificación 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 análisis, 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 pertenecían a capas con un nivel de abstracción superior. En este sentido, se considera principalmente los puntos extremos del modelo, en donde se realizan las diferentes instrucciones que interactúan con los vehículos, la creación de la flota inicial de transporte, y la obtención del perfil del cliente para conocer los usuarios que utilizan el servicio; siendo no relevante para el proyecto la lógica resolutiva del sistema de transporte de pasajeros respecto a la toma de decisiones.

Los parámetros 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 visualización 3D, en caso de ser así, se debe especificar la ruta de otro archivo, el cual contiene la información sobre la distribución de los diferentes nodos involucrados en la creación del mapa 3D.

El nuevo agente Manager3D del diagrama de identificación de agentes (ver Figura 5.2), es el encargado de todo lo relacionado con la creación y administración del entorno 3D, como es la generación del escenario, la actualización de los eventos, la creación de los vehículos y clientes, etc. La información requerida por el agente Manager3D, se obtiene a partir de la incorporación de nuevas funcionalidades a los agentes del sistema de transporte. Estas funcionalidades consisten en la capacidad de transmisión de información respecto a los eventos que estos realizan, principalmente lo que es la creación de vehículos (SchedGen), la creación de clientes (TripGen), y la actualización de eventos en los vehículos (EventVehicle).

El ciclo de vida del motor gráfico comienza con la inicialización del sistema, en el cual se obtiene la información de los parámetros 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 implementación del bucle principal, cada motor gráfico posee un bucle en el cual se realizan todas las operaciones que debe estar continuamente realizando, con la actualización final de la pantalla; en este caso, los procedimientos implementados en este bucle consideran la actualización del estado de cada uno de los vehículos del sistema, con el fin de calcular el comportamiento que estos tendrán en la interfaz 3D. Finalmente el ciclo de vida termina cuando se cierra la aplicación.

Las funcionalidades otorgadas por la interfaz gráfica son: mostrar detalles del bus, mostrar detalles de clientes y cambiar la cámara. 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 cámara, tiene como objetivo otorgar diferentes puntos de vista al usuario respecto a la posición 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 inicialización 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 solución se pospuso en post de continuar con la programación de la interfaz.

Figura 5.4 Modelos 3D proyecto relacionado [Baranlloni, 2009]

Los modelos 3D utilizados en el desarrollo de la interfaz fueron: el vehículo 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

Capítulo 6: Desarrollo del Proyecto

6.1 Presentación del Caso de Estudio

El problema que se aborda en este proyecto posee varios puntos. La motivación principal es el realizar una representación gráfica de componentes internos de un sistema, para su posterior análisis y comprensión. Si bien algunos elementos del sistema seleccionado no serán representados en su exactitud, se buscará realizar una aproximación lo más cercana a su funcionamiento. A continuación 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 ejecución, esto no quiere decir que la interfaz gráfica también lo será, principalmente por la diferencia de paradigma utilizado en la implementación del software. El primer problema vendría a ser la representación tardía de tareas que se pueden estar realizando en el Sistema Multiagente hacia el motor gráfico, al igual que la ejecución de comandos externos que no se vean rápidamente reflejados en el sistema interno; mientras que el segundo problema, es que la realización 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 estación y continua por cada una de las calles, deteniéndose en los diferentes puntos en donde se puedan subir o bajar clientes, y se termina al volver a su punto de origen.

• Incompatibilidad gráfica: Debido a que cada uno de los modelos 3D pertenecientes al sistema se diseñan en un software de modelado independiente del motor gráfico, 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 gráfica, como también 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 Tecnologías Utilizadas

En este proyecto se aplicarán diversas tecnologías y conceptos expuestos en capítulos 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 utilización del motor gráfico jMonkeyEngine, debido principalmente a que ambos software trabajan con el lenguaje de programación Java, evitando de esta forma posibles errores de compatibilidad al momento de querer intercambiar información.

Para el desarrollo de cada uno de los elementos que conformarán el entorno 3D, se ha optado por la utilización del software de modelado Blender, ya que como se mencionó anteriormente, es gratuito y otorga una gran serie de herramientas, siendo además el software de modelado recomendado por la comunidad de programadores y diseñadores de jMonkeyEngine.

La parte del diseño del proyecto relacionada con el Sistema Multiagente se realizará mediante la utilización de la metodología de desarrollo de agentes PASSI, mientras que el diseño del funcionamiento del motor gráfico se realizará mediante la utilización de diagramas UML, este cambio de metodología 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 ubicarán los vehículos, clientes y los diferentes puntos de recolección, a partir de los cuales se podrán subir y bajar los clientes del servicio de transporte según las solicitudes de viajes que estos hayan realizado. Además, se incorporará la estación de buses, utilizada principalmente para la generación de los buses, su salida y retorno.

Los parámetros de entrada se obtendrán a partir de un archivo de texto, el cual se utiliza principalmente para la inicialización del sistema de transporte con el cual se está trabajando, en este caso, además se le añadirá la opción de utilizar o no la interfaz gráfica, de ser así, se generará el mundo virtual básico, al cual se le irán añadiendo más elementos a medida que este vaya obteniendo información.

Eliminado: s

62

Todos los elementos pertenecientes al mundo serán representados con un modelo 3D en particular, entre los que se encuentran: vehículos, clientes, paraderos, edificios, estación, 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. Además, tanto la ciudad como la localización de los paraderos y la estación de los buses se establecerán de forma fija, principalmente para modelar el mundo 3D de forma mucho más detallada, centrándose 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 información necesaria de los otros agentes involucrados, como también de realizar diversos comportamientos en el sistema. A los agentes ya implementados en el sistema de transporte, se les añadirá la característica de poder informar su estado y comportamiento actual al agente de interfaz, permitiendo de esta forma captar esta información y enviársela al motor gráfico para que este pueda procesarla y transformarla a representaciones visuales del sistema.

La interacción con las diferentes entidades 3D del entorno se realizará mediante el despliegue de un panel de información 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 vehículos. Algunos de estos eventos pueden ser por ejemplo: la cancelación de una solicitud de viaje, el abandono del punto de recolección de un cliente, el atraso de un bus en su tiempo de salida o su detención mientras se movilizaba por algún imperfecto.

Otros eventos que también serán incorporados, pero no tienen una relación directa con el Sistema Multiagente son: la capacidad de modificar la cámara, por ejemplo, asignársela a un determinado vehículo 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 Diseño del Sistema

6.2.1 Análisis del Sistema Existente

A partir del análisis del proyecto presentado en apartado 5.5 se puede obtener una visualización previa del diseño del simulador del sistema de transporte relacionado con la captura de la información.

Como se mencionó anteriormente, el nuevo agente denominado Manager3D se encargará de obtener información de los otros agentes del sistema, enviándosela posteriormente al motor gráfico para su posterior procesamiento y representación, este nuevo agente además podrá inducir comportamientos en los eventos de los vehículos y de los clientes


63

del sistema de transporte. En la Figura 6.1 se presenta el diagrama de Descripción del Dominio realizado en [Donoso y Sandoval, 2009].

CrearMapa

GestionarMapa

<<include>>

GestionarPropuestas

ProcesarSolicitudes

GestionarEventos

<<include>>

<<c>>


GenerarFlota

Vehiculos

<<include>>


GenerarEventos

Trip-Request


<<include>>

<<include>>


GenerarMatchingVehiculos

<<include>>




<<include>>

<<include>>


ProcesarEventosExternosVehiculos


GenerarPropuestas

<<include>>

MostrarEventosVehiculos

<<include>>

<<c>>

<<c>>

<<c>>

<<c>>

<<c>>

<<c>>

<<c>>

<<c>>

NegociarPropuestas




<<c>>

<<c>>

<<c>>



<<include>>

<<include>><<c>>

<<c>>

<<c>><<include>>

<<include>>

<<include>>

<<c>>

<<c>>

Monitor

<<c>>

Figura 6.1 Descripción del dominio proyecto relacionado [Donoso y Sandoval, 2009]

A partir del diagrama anterior, se consideran principalmente las funcionalidades que interactúan directamente con el motor gráfico, obviando en gran parte de las que están ligadas con la lógica resolutiva del problema. A continuación se presentan los casos de uso necesarios para la creación de la interfaz 3D:

• Obtener Eventos Vehiculos: Genera los eventos del lado del vehículo, 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 interacción externa con el motor gráfico hacia el Sistema Multiagente, también se podrán crear nuevos eventos en los vehículos a partir de la interacción con los diferentes vehículos 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 vehículo, o bien, cancelaciones. Al igual que en Obtener Eventos Vehiculos, también se pueden crear nuevos eventos en un cliente, mediante la interacción 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 vehículo debido a desvíos, congestiones o fallas. Tanto si se ha especificado una captura de eventos mediante una simulación 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 gráfica.

• Generar Eventos Cliente: Gestiona los eventos que se van produciendo mientras dura la ejecución 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 características 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 características de los diferentes clientes 3D ubicados en el mundo.

• Generar Flota Vehiculos: Genera los vehículos que interactúan 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 vehículos, como también de permitir re-planificaciones en caso de que surjan imprevistos en la realización del servicio. Otra de las funcionalidades internas que realiza el sistema, es la gestión y creación 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 realización de un servicio de transporte solicitado por un cliente.

6.2.2 Modelo Requerimientos del Sistema

En este primer modelo de la metodología de desarrollo de agentes PASSI, se ha obviado del diagrama de descripción del dominio, debido a su explicación realizada en la sección anterior, procediendo directamente a la especificación de las nuevas funcionalidades e interacciones del agente Manager3D.

6.2.2.1 Identificación de Agentes

65

En la Figura 6.2 se puede observar el mismo diagrama de identificación de agentes presentado en el artículo 5.5, el cual se ha modificado con el fin de adecuarse a los nuevos requerimientos de la interfaz. Este básicamente realiza las mismas funcionalidades, pero ahora incorporando el inducir eventos en los agentes EventVehicle y EventClient, además de la comunicación entre Generar Eventos Clientes y Procesar Visualizacion Eventos.

Manager3D

Schedule

Map

SchedGen

TripGen

Broker

EventClient

TripRequestPlanner

EventVehicle

CrearMapa

GestionarMapa

<<include>>

GestionarPropuestas

ProcesarSolicitudes

GestionarEventos

<<include>><<c>>


GenerarFlota

Vehiculos<<include>>


GenerarEventos

Trip-Request


<<include>>

<<include>>


GenerarMatchingVehiculos<<include>>




<<include>>

<<include>>


Procesar EventosExternosVehiculos


GenerarPropuestas

<<include>>MostrarEventosVehiculos

<<include>>

<<c>><<c>>

<<c>> <<c>>

<<c>>

<<c>>

<<c>>

<<c>>

NegociarPropuestas




<<c>>

<<c>>

<<c>>



<<include>>

<<include>>

<<c>>

<<c>>

<<c>>

<<include>>

<<include>>

<<include>>

<<c>>

<<c>>

GenerarMapa 3D

GestionarMotor 3D

<<include>>

ProcesarVisualizacionEventos

GestionarDatos

<<include>>

<<c>>

<<c>>

<<c>>

Monitor

<<c>>

InducirEventosInternos

<<c>>

<<c>>

<<c>>

<<include>>

<<include>>

Figura 6.2 Diagrama de identificación de agentes [Elab. Propia]

Con formato: Normal,Interlineado: sencillo


66

A partir del diagrama de descripción del dominio presentado en el artículo 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 continuación:

• 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 información 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 también de capturar los diversos eventos obtenidos de los vehículos por el caso del caso de uso Generar Eventos Vehiculos.

• Gestionar Motor 3D: Realiza la interacción entre el motor gráfico y el Sistema Multiagente, ya sea enviando información del sistema de transporte hacia la interfaz, o bien recibiendo comportamientos desde la interfaz y enviándoselos sistema de transporte.

• Generar Mapa 3D: Se ejecuta al inicializar el agente Manager3D, capturando la información necesaria para la inicialización del motor gráfico y la posterior creación del entorno.

6.2.2.2 Identificación de Roles

En esta fase se analizan los diferentes escenarios y roles que se encuentran involucrados en la interacción 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 información proveniente de los demás agentes, como también de la interacción con el motor gráfico; mientras que el segundo se encarga de la captura y envío de los eventos seleccionados por el cliente de la interfaz, hacia los agentes correspondientes en el Sistema Multiagente (vehículos o clientes).

Debido al tipo de interacción 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 identificación de agentes presentado en el artículo 5.5, el cual se ha modificado con el fin de adecuarse a los nuevos requerimientos de la interfaz. Este básicamente realiza las mismas funcionalidades, pero ahora incorporando el inducir eventos en los agentes EventVehicle y EventClient, además de la comunicación entre Generar Eventos Clientes y Procesar Visualizacion Eventos.¶

67

posee el rol GeneradorDeVehiculos, encargado de generar los diferentes vehículos para suplir la demanda de solicitudes de viaje e informar al agente Manager3D de su creación.

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 información inicial [Elab. Propia]

La Figura 6.3 muestra el escenario inicial del sistema, en el cual, a partir de la inicialización del simulador por parte del agente MainAgent, se obtiene la información correspondiente del grafo a utilizar por el sistema, la que posteriormente se envía al agente Manager3D para la inicialización y generación del entorno 3D en el motor gráfico. Tanto la creación de la flota inicial de vehículos como la generación 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 vehículo a partir de la interfaz 3D. Luego de haber seleccionado el evento correspondiente a un vehículo 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 envía 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


GeneradorDeEventos: EventVehicle

ProcesadorDeEventos: Schedule

GeneradorEventos: Manager3D

1 : inducirNuevoEventoVehiculo()

2 : crearEventoVehiculo()

3 : procesarAccion()

4 : resultadoAccion()

5 : informarResultadosEventoVehiculo()

6 : procesarEventos()

Figura 6.4 Escenario de generación de evento en vehículo [Elab. Propia]

Al igual que en el escenario anterior, en la Figura 6.5 se puede observar la generación de un evento hacia el cliente del servicio de transporte, en donde las funcionalidades de los dos roles pertenecientes al agente Manger3D interactúan de forma similar con los roles GeneradorDeEventos y ComunicadorDeEventos del agente EventClient.

Si bien, tanto los eventos el vehículo 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 bastaría con crear internamente de forma aleatoria el evento por parte del agente EventVehicle o el agente EventClient, saltándose 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


GeneradorDeEventos: EventClient

GestionadorDeSolicitudes: TripRequest

GeneradorEventos: Manager3D

1 : inducirNuevoEventoCliente()

2 : crearEventoCliente()

3 : procesarAccion()

4 : resultadoAccion()

5 : informarResultadosEventoCliente()

6 : procesarEventos()

Figura 6.5 Escenario de generación de evento en cliente [Elab. Propia]

6.2.2.3 Especificación 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 demás agentes, comenzando en un principio por el envío de la información de los vehículos para la inicialización del motor. Las diferentes solicitudes de viaje de los clientes son gestionadas para luego ser utilizadas cuando se requieran. La creación de los eventos en los vehículos y clientes, se realizan en los agentes correspondientes para posteriormente ser procesados por el agente Manager3D, siendo finalmente gestionados y enviados al motor gráfico.


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 task>>

EventVehicle.surgirEventoSimulado<<EventVehicle task>>

TripGen.generarSolicitudViaje<<TripGen task>>

gestionarDatos

capturarEventoClienteInterfaz

inducirNuevoEventoCliente

EventClient.surgirEventoSimulado<<EventClient task>>

EventClient.capturarEvento<<EventClient task>>

EventClient.generarNuevoEvento<<EventClient task>>

Figura 6.6 Especificación 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 también las dependencias que los componen. Se han extendido las características de los diagramas realizados en el diseño del simulador del sistema de transporte inicial en donde se posee una relación directa con el agente Manager3D, por lo que se presentarán únicamente los agentes e interacciones que se encuentren involucrados con dicho agente. Cabe mencionar que se ha obviado de la descripción del dominio, ya que los diversos conceptos, predicados y acciones corresponden al sistema de transporte como tal (ver Figura A.1). De manera similar, también se ha obviado de la descripción 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 Descripción de Ontología de Comunicación

En este diagrama se especifican los diferentes tipos de comunicación realizados entre los agentes que componen el sistema mediante la utilización de diagramas de clases. Las comunicaciones son definidas por la relación entre dos agentes, y se detallan en su clase los atributos de dicha relación, los cuales son: la ontología, el lenguaje de comunicación y el protocolo de interacción.

Manager3D<<Agent>>

EventClient<<Agent>>

TripGen<<Agent>>

SchedGen<<Agent>>

EventVehicle<<Agent>>

SchedGen-Manager3D<<communication>>

+Ontology: Informar+Language: FIPA ACL+Protocol: none

TripGen-Manager3D<<communication>>


EventClient-Manager3D<<communication>>


EventVehicle-Manager3D<<communication>>


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 Descripción de ontología de comunicación [Elab. Propia]

Como se mencionó anteriormente, debido al carácter informativo de la comunicación que existe entre los diferentes agentes involucrados en el sistema, no se ha necesitado de un protocolo de interacción ya definido para el envío 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 ontologías de comunicación básicas para la especificación de conceptos comunes en el dominio.



72

6.2.3.2 Descripción de Roles

Manager3D<<Agent>>

GestorEntorno : Manager3D

-gestorEntorno()-inicializarMotorGrafico()-recibirActualizacionMundo3D()



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 vehículo

inducir evento vehículoinducir evento cliente

informar datos cliente informar creación vehículo

[Cambio Rol] [Cambio Rol]

[Cambio Rol]

Figura 6.8 Descripción de roles [Elab. Propia]


73

El diagrama de descripción de roles corresponde a un diagrama de clases, en donde los agentes se encuentran agrupados en paquetes y sus roles en clases, la relación 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 ejecución 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 vendría a ser la gestión de la información para su envío al motor gráfico y la generación de eventos hacia los clientes y vehículos. Los nombres de las acciones se han simplificado, por lo que no representan realmente los métodos necesarios a implementar por los agentes, esto se verá en la siguiente fase de la metodología PASSI.

6.2.4 Modelo de Implementación de Agentes

En este tercer modelo de PASSI, se busca representar la solución de la arquitectura del en términos de clases y métodos, 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 descripción del comportamiento de los agentes, debido a que no es relevante para el posterior desarrollo e implementación del sistema.

6.2.4.1 Definición de la Estructura Multiagente

En esta fase se hacen uso de diagramas de clases para representar la estructura de la solución del Sistema Multiagente. En la Figura 6.9 se puede observar una aproximación más cercana a la implementación 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 relación entre el Sistema Multiagente y el motor gráfico es la variable “app” , la cual almacena el motor gráfico como tal en su completitud. A partir de esta variable se inicializa el sistema gráfico y las propiedades de la ventana, como también se realiza todo el proceso de envío y captura de información del entorno mediante la llamada de sus diversos métodos públicos.

La no utilización de una cantidad de variables tan extensa se debe a que el agente Manager3D actúa principalmente como un intermediario entre el simulador de transporte y la interfaz gráfica, este realiza el procesamiento cuando es necesario y llama a los métodos de la interfaz 3D, sin tener que almacenar información de lo realizado, como puede ser el listado de vehículos o clientes, las diferentes solicitudes de viajes, el grafo donde se almacena la información 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

-inicializarMotorGrafico()-recibirActualizacionMundo3D()-inducirEvento()


+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

-informarActualizacion3D()-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

-informarActualizacion3D()-Generate_schedule_agents_Behaviour()


+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

-informarActualizacion3D()-Create_events_Behaviour()-Create_events_Behaviour_3D()-Trip_simulator_Behaviour()

Figura 6.9 Definición de la estructura Sistema Multiagente [Elab. Propia]

Los métodos del agente Manager3D son:

• inicializarMotorGrafico: Encargado de generar una instancia del motor gráfico, enviar los datos necesarios para su inicialización y posteriormente ejecutarlo.

• recibirActualizacionMundo3D: Se encarga de enviar hacia el motor gráfico los diferentes cambios realizados en el Sistema Multiagente (cancelación de un viaje por parte del cliente, problemas en la vía, ausencia de un cliente en su paradero de recogida, entre otros).


75

• inducir Evento: Captura el evento del vehículo o del cliente en la interfaz y lo envía al agente EventVehicle o al agente EventClient correspondientemente. La reacción luego de generar el evento es capturada por el método explicado anteriormente (denominado como recibirActualizacionMundo3D).

6.2.4.2 Definición 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 solución, 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 continuación se explican los diferentes comportamientos definidos para los agentes:

• Agente Manager3D (Figura 6.10):

• recibirActualizaciónMundo3D: Definido como un CyclicBehaviour, en el cual se podrán 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 método informarActualizacion3D.

• Agente SchedGen (Figura 6.12):

• Generate_schedule_agents_Behaviour: Hace uso de un OneShotBehaviour para informar de la creación de los diversos vehículos, en este caso se realiza una sola vez, ya que se envía 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 gráfico.

76

• Trip_simulator_Behaviour: Obtiene la información de las solicitudes que generan los clientes hacia los vehículos 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 gráfico.

Manager3D<<Agent>>

-Interfaz3D app-int width-int height-boolean isVSync-boolean isFullscreen-boolean isPausedInLostFocus-boolean isDisplayStats-boolean isDisplayFps-int antialiasingValue

-inicializarMotorGrafico()-recibirActualizacionMundo3D()-inducirEvento()

JADEAgent(from JADE)

<<Agent>>

CyclicBehaviour(from JADE )

<<Agent>>

SimpleBehaviour(from JADE)

<<Agent>>Behaviour(from JADE)

<<Agent>>

recibirActualizacionMundo3D<<Task>>

-recibirActualizacionMundo3D()

Figura 6.10 Definición 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

-informarActualizacion3D()-Generate_trip_agents_Behaviour()


<<Agent>>

Behaviour(from JADE)

<<Agent>>

Generate_trip_agents_Behaviour()<<Task>>

TickerBehaviour(from JADE)

<<Agent>>

Figura 6.11 Definición 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

-informarActualizacion3D()-Generate_schedule_agents_Behaviour()


<<Agent>>

OneShotBehaviour(from JADE)

<<Agent>>SimpleBehaviour(from JADE)

<<Agent>>

Behaviour(from JADE)

<<Agent>>

Generate_schedule_agents_Behaviour()<<Task>>

Figura 6.12 Definición de la estructura agente SchedGen [Elab. Propia]



78


+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

-informarActualizacion3D()-Create_events_Behaviour()-Create_events_Behaviour_3D()-Trip_simulator_Behaviour()


<<Agent>>


<<Agent>>



<<Agent>>


<<Agent>>

Create_events_Behaviour_3D<<Task>>

Create_events_Behaviour<<Task>>

Trip_simulator_Behaviour<<Task>>

Figura 6.13 Definición de la estructura agente EventVehicle [Elab. Propia]


+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()


<<Agent>>



<<Agent>>

Create_events_Behaviour_3D<<Task>>


<<Agent>>


<<Agent>>

Create_events_Behaviour<<Task>>

Figura 6.14 Definición 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 básicamente contiene toda la información necesaria para la inicialización 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á compresión de la matriz, establecer el número de ejecuciones que se realizarán, indicar el directorio, entre otros.

En la Tabla 6.1 se puede observar los diversos datos utilizados por el simulador, además de la incorporación de la línea “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 estática, por lo que a diferencia del proyecto realizado en [Baranlloni, 2009], se ha descartado la utilización 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 inicialización del sistema.

Tabla 6.1 Archivo de inicialización 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 Diseño Motor Gráfico

80

En este apartado se realizará la fase de diseño correspondiente al funcionamiento del motor gráfico, en donde se identificarán por una parte las características otorgadas al usuario de la interfaz, y por otra las funcionalidades realizadas de forma interna por el motor, considerando un diseño no exhaustivo del mismo, lo que quiere decir que solo se evaluarán los puntos fundamentales para la posterior implementación 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 identificarán 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 gráfico al usuario de la interfaz (ver Figura 6.15), estas funcionalidades de forma general consisten en:

• Modificar Cámara: Permite modificar la velocidad y localización de la cámara con la cual se observa el entorno. Respecto a su localización, esta puede ser fijada sobre alguna otra entidad (cliente o vehículo), otorgando una visión en tercera persona, o ser localizada en modo espectador, permitiendo modificar de forma manual su ángulo y posición.

• Modificar Vehículo: Permite obtener información sobre un determinado vehículo, inducir un nuevo evento, o fijarle la cámara para realizarle un seguimiento en tercera persona.

• Modificar Cliente: Al igual que en el modificar vehículo, esta funcionalidad permite obtener información sobre un determinado cliente, inducir un nuevo evento, o fijarle la cámara en tercera persona.

81

System

UsuarioInterfaz

DesplegarSub-MenúCliente

DesplegarSub-MenúVehículo

DesplegarSub-Menú

Nodo

MostrarDatosCliente

MostrarDetalleVehículo

<<extend>>

<<extend>>

InducirEventoCliente

<<extend>>

InducirEventoVehículo

<<extend>>

FijarCámaraVehículo

<<extend>>

FijarCámaraCliente

<<extend>>

MostrarDatos Nodo

<<extend>>

SeleccionarNodo Parada

SeleccionarVehículo

SeleccionarCliente

<<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 CapturaPantalla por Mouse

Crear Skybox Cielo

Crear Iluminacióny Sombras

Cargar ModeloEscenario Ciudad

Iniciar Interfaz

Cargar ModeloVehículo 3D

Cargar ModeloCliente 3D

Inicializar DatosVehículo

lista vehiculos incompleta

Iniciar Música

Inicializar DatosCliente

Generar Path Finding

nueva solicitud viaje

Inicio Bucle Motor

fin generación vehículos

Actualizar EstadoVehículo

cambio estado/evento vehículo

Actualizar Pantalla

continua aplicación

fin aplicación

ningún cambio vehículo

sin solicitudes viaje

CambiarCaracterísticas

Cámara

cambio estado/evento cliente

Actualizar EstadoCliente

ningún cambio cliente

modificar cámara no modificar cámara

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 envío de información al Sistema Multiagente, con la posterior actualización de la pantalla.

El motor gráfico, 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 rotación de la cámara se realiza únicamente seleccionando la pantalla, permitiendo de esta forma liberar el control de recursos que produce la aplicación.

• El “skybox”, el cual consiste en el medio para la creación del cielo en la ciudad, esto se realiza utilizando un cubo texturizado en su interior, el cual cubre todo el entorno, dando la sensación al usuario de estar mirando al cielo.

• La creación de las diferentes luces (tanto ambientales como luces direccionales para el sol) y la activación de las sombras en las diferentes geometrías.

• La generación de la ciudad 3D, la cual almacena los diferentes edificios, veredas, paraderos y calles, además de la estación para los vehículos.

• La creación del “Path Finding” , para que los diferentes vehículos puedan transitar por las calles. Esto se realiza mediante la utilización de un conjunto de vectores rectilíneos y curvos definidos por jMonkeyEngine para el desplazamiento de geometrías.

• La inicialización y activación de la música ambiental.

• Finalmente la carga de los diferentes vehículos 3D, proceso que se realiza de forma indefinida hasta que ya se hayan cargado todos los vehículos del sistema establecidos en la lista enviada por el agente Manager3D.

Una vez realizado todo este proceso de inicialización del entorno, comienza el bucle del motor, el cual es fundamental para la mayor parte de las aplicaciones gráficas. Este bucle se encarga de realizar todos los procesos que tienen que estar continuamente calculándose, como el movimiento de geometrías, la captura de información, control de colisiones, aplicación de físicas, 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 vehículos, de ser así, se deben actualizar los datos de dicho vehículo 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 actualización como respuesta.

84

Si se desea modificar la cámara, entonces se realizan los cambios en sus características. Finalmente se muestran por pantalla todos los cambios producidos anteriormente, y se evalúa si se seguirá ejecutando la aplicación.

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 gráfico, encargado de procesar toda la información obtenida y actualizarla por pantalla.

• Vehiculo3D: Clase que contiene toda la información y acciones posibles que puede realizar cada uno de los vehículos en el mundo 3D.

• Cliente3D: Clase que contiene la información 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

-SimpleApplication app+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

-SimpleApplication app-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 Diseño de la Ciudad

En la Figura 6.18 se presenta el grafo no direccionado utilizado para la creación de la ciudad, en este diagrama se pueden identificar 13 nodos, los cuales corresponden a los diferentes pares de paraderos en donde los clientes podrán realizar las diversas solicitudes de viaje, el enlace entre estos nodos representa las calles por donde transitarán los vehículos, las cuales se han establecido en ambos sentidos.


86

Nodo/paradero

de la ciudad

Calle por donde

transitan los vehículos

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 aproximación más cercana de la implementación que se realizará de la ciudad. En este diagrama se pueden identificar dos paraderos por nodo, esto se debe a que los vehículos para poder tomar o dejar clientes, solo pueden transitar por la vía que corresponda al sentido en que se dirige dicho vehículo.

La estación de los buses se ha creado en la parte norte de la ciudad, en donde en un comienzo se ubicarán todos los buses definidos en el archivo de entrada, una vez estos buses hayan realizado su recorrido, se devolverán al punto de origen.

La creación de los clientes se realizará únicamente en las cercanías de los paraderos en donde estos realizarán sus solicitudes de viaje, y tendrán que esperar allí hasta que llegue el vehículo que los recogerá, o hasta que se genere un evento que cancele su solicitud, realizando la animación correspondiente. Además, una vez asignado un determinado paradero al cliente, se realizará de forma aleatoria su asignación 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 vehículos se desplazará de forma continua por los diferentes caminos de la ciudad en relación al nodo destino hacia el cual debe ir, por lo que se obviará el sistema de colisión que podría generarse cuando dos vehículos se interpongan entre sí, ya que esto implicaría una modificación en el simulador, lo que impediría el cumplimiento de los objetivos propuestos para este proyecto.

En el diagrama anterior se puede observar que las rutas de los vehículos, al desarrollarse en ambos sentidos, implica el tener que reorganizar la ruta próxima antes de empezar a mover el bus, ya que este nunca debe transitar por la vía contraria a su sentido.

Capítulo 7: Pruebas de Software

La realización de pruebas es fundamental para verificar que se estén realizando de forma correcta las funcionalidades que debe cumplir la aplicación, como también validar que el


Con formato: Justificado,Sangría: Primera línea: 0,95cm


88

proceso de implementación 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 considerarán ciertos criterios para elegir buenos casos de prueba.

7.1 Planificación de las Pruebas

El plan de pruebas de forma general tiene como objetivo determinar el esquema de actividades de prueba, así como también el enfoque, los elementos a probar, sus características y los criterios a utilizar.

Debido al tipo de aplicación con la cual se está trabajando, los enfoques seleccionados para la realización de las pruebas serán principalmente de caja negra y de caja blanca, en donde se evaluarán las entradas y salidas correspondientes del sistema, considerando además el funcionamiento interno del mismo. Se han escogido estos tipos de prueba, debido a que es necesario ver la forma en que interactúa la interfaz con el medio que lo rodea (el cual en muchos casos depende de los cambios externos y la información enviada desde otras fuentes), además 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 triángulos, calidad de texturas, calidad de las sombras, entre otros) y la capacidad del hardware con el cual se están realizando dichas pruebas. Cabe mencionar, que la realización de estos tipos de pruebas se ejecutará en conjunto, dependiendo principalmente de que es lo que se desee evaluar.

Los elementos que se probarán en un comienzo corresponden a datos pertenecientes a la fase de inicialización de la aplicación, como la activación de la sincronización vertical, la correcta resolución de pantalla, la generación de un skybox, la carga de texturas, etc. Luego se realizarán pruebas relacionadas con la inicialización, pero ejecutadas únicamente por el motor gráfico. Posteriormente se realizarán pruebas de interconexión con el Sistema Multiagente, en donde se evaluará que se esté llevando a cabo de forma correcta la captura y creación de los diferentes datos/eventos por parte del agente Manager3D, como también la correcta implementación de la información obtenida en el motor gráfico. Las pruebas de rendimiento mencionadas anteriormente se ejecutarán en conjunto con las demás pruebas.

7.2 Diseño de las Pruebas

A continuación se definirá como se llevarán a cabo las diversas pruebas planificadas para posteriormente obtener resultados esperados. El diseño relativo a las pruebas de caja

89

negra consiste principalmente en la evaluación de un conjunto de escenarios con determinados puntos de entrada y salida, el diseño de las pruebas de caja blanca se centra en las funciones internas de un módulo, y el diseño del rendimiento de la aplicación consiste en la modificación directa en la calidad tanto de geometrías como de texturas y sombras.

El proceso de prueba comienza con la modificación 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 realizarán modificaciones en la activación/desactivación del VSync, cambios en la resolución de la pantalla y el aumento o disminución de la calidad del antialiasing. Los datos esperados para estas modificaciones se presentan en las tablas siguientes:

Tabla 7.1 Prueba activación/desactivación VSync [Elab. Propia]

Nombre Prueba Activación/desactivación sincronización vertical. Descripción La activación o desactivación de la sincronización vertical implica la

modificación directa de la cantidad de frames por segundo (fps) implementada en un motor gráfico. En el caso de estar activada, los fps generados por el hardware gráfico 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 aparición de ciertos errores gráficos, como la desaparición de geometrías, desfase de la pantalla, líneas intermitentes horizontales, entre otros.

Entradas Activación o desactivación del filtro. Salidas Los resultados de la cantidad de fps y la aparición o no de errores gráficos.

Tabla 7.2 Prueba cambios en resolución de la pantalla [Elab. Propia]

Nombre Prueba Cambios en la resolución de la pantalla. Descripción Los cambios en la resolución de la pantalla deben tener como consecuencia una

modificación 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 Generación de la ventana.

Tabla 7.3 Prueba aumento/disminución calidad antialiasing [Elab. Propia]

90

Nombre Prueba Aumento/disminución calidad filtro antialiasing. Descripción El aumento o disminución de la calidad en el filtro antialiasing permite

especificar la técnica que utilizará el motor gráfico para eliminar el dentado en los bordes de las imágenes. Es muy importante corroborar que este filtro no juega un papel fundamental en el rendimiento final de la aplicación, de lo contrario, es mejor no hacer uso de él.

Entradas El número 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 inicialización de los diferentes modelos 3D, la generación de luces y sombras, activación de la música, funcionamiento correcto del Path Finding y la implementación del skybox. Los datos esperados son:

Tabla 7.4 Prueba iniciación y carga de modelos 3D [Elab. Propia]

Nombre Prueba Iniciación y carga de los modelos 3D. Descripción La iniciación de los modelos 3D involucra la generación de las entidades con

sus características generadas de forma correcta (no haya sido escalado en uno o más ejes, o se encuentre en una posición errónea), el Mapping de la textura realizada de forma exacta (la textura creada se aplique correctamente en la geometría) y posea todos los polígonos que se hayan especificado.

Entradas La textura y el objeto que contiene toda la información de la geometría. Salidas La visibilidad del modelo 3D con la carga de su respectiva textura.

Tabla 7.5 Prueba creación de luces y sombras [Elab. Propia]

Nombre Prueba Creación de luces y sombras. Descripción La creación de luces debe afectar a todas las geometrías de la escena sin

excepción, independiente si esta es ambiental o direccional. La captura y generación de sombras debe ser activada por una parte en el motor gráfico y por otra en cada una de las geometrías 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 dirección y el color que irradia, además de la sombra que se desea crear. En este caso son dos luces, las cuales se especificarán de forma separada.

Salidas Los cambios del brillo en los diferentes objetos y la proyección de su sombra.

Tabla 7.6 Prueba creación de la música ambiental [Elab. Propia]

91

Nombre Prueba Creación de la música ambiental. Descripción La música se iniciará de forma automática al comenzar la aplicación, se debe

comprobar que esta se ejecuta de forma indefinida y con un volumen moderado. Hasta el momento solo se posee un archivo de música, pero es suficiente para la realización de las pruebas correspondientes.

Entradas El archivo que almacena la música. Salidas Si este archivo se reproduce de forma correcta en el motor.

Tabla 7.7 Prueba aplicación del Path Finding [Elab. Propia]

Nombre Prueba Aplicación del Path Finding. Descripción Respecto al Path Finding, se debe probar que sea aplicado de manera exacta a la

ciudad creada y que los diferentes vehículos sean capaces de seguirlo en la dirección correspondiente al sentido de la calle.

Entradas Los diferentes vectores, sus sentidos y posiciones sobre la ciudad. Salidas Si las geometrías pueden recorrer dichos vectores, y si lo realizan de manera

fluida.

Tabla 7.8 Prueba creación del skybox [Elab. Propia]

Nombre Prueba Creación del skybox. Descripción Se utilizará la técnica del skybox para la generación del cielo que rodea la

ciudad, el cual independiente del tamaño de las geometrías que se encuentren en su interior, se podrá observar de igual manera.

Entradas El objeto que almacena la geometría (caja) con las 6 imágenes interiores del cielo.

Salidas La existencia de errores en las conexiones que se producen entre las diferentes caras de la caja, especialmente si las imágenes han sido aplicadas a dichas caras en el ángulo correcto.

Las pruebas relacionadas con la interconexión entre el motor gráfico y el Sistema Multiagente van destinadas únicamente al envío o captura de la información, y la recepción correcta de los resultados en las diferentes geometrías 3D involucradas (en especial los vehículos y los clientes).

Además de este tipo de pruebas, también se evaluarán las que tienen que ver con la interacción del sistema de forma general, es decir, todas las acciones que no se realicen de forma automática o simulada, por ejemplo la asignación de la cámara a un determinado cliente del servicio.

A continuación se explican los casos de prueba realizados para esta última etapa del diseño de pruebas:


92

Tabla 7.9 Prueba modificación de la cámara [Elab. Propia]

Nombre Prueba Modificación de la cámara. Descripción Como se mencionó anteriormente, la cámara puede ser asignada en modo

espectador o fijada en una entidad, por lo que se debe poder probar su correcto funcionamiento.

Entradas La acción a realizar sobre la cámara, ya sea cambiándole de modo, rotándola, moviéndola o fijándola.

Salidas Si la acción se ve reflejada de manera correcta, ubicando la cámara en un ángulo y posición cómodos para el usuario.

Tabla 7.10 Prueba captura de evento [Elab. Propia]

Nombre Prueba Captura de evento. Descripción En esta prueba se busca corroborar que la captura de eventos se realice de

forma correcta en el motor gráfico, con los parámetros necesarios y en el momento adecuado. Estos eventos pueden luego verse reflejados en los clientes o en los vehículos.

Entradas El evento obtenido del Sistema Multiagente. Salidas La acción realizada sobre la entidad especificada en el evento, esperando que

esta se haya realizado de forma correcta.

Tabla 7.11 Prueba generación de evento [Elab. Propia]

Nombre Prueba Generación de evento. Descripción 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 acción generado en el Sistema Multiagente, el que además

debe ser enviado al motor gráfico para presentar el resultado al usuario de la interfaz (la realización de la acción en caso exitoso, o la aparición 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 gráfico utilizarán. Específicamente se utilizarán 13 paraderos, 15 buses, y 50 clientes. En la Tabla 7.12 se muestra la matriz simétrica 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 información 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 información [Donoso y Sandoval, 2009]:

nodo_o nodo_d d_tiempo d_costo

Dónde:

• nodo_o: Nodo origen.

• nodo_d: Nodo destino.

• d_tiempo: Distancia en tiempo.

• d_costo: Distancia en costo.

Los datos de los buses también 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 vehículos en cada columna posee la siguiente información [Donoso y Sandoval, 2009]:

id_v cap nodo_o nodo_d

Dónde:

• id_v: Identificador del vehículo.

• cap: Capacidad máxima de pasajeros.

• nodo_o: Nodo depósito de origen.

• nodo_d: Nodo depósito de destino.

Finalmente se utilizará el archivo “clientes.txt” (ver Tabla 7.15) para obtener la simulación de peticiones de viaje de un conjunto de clientes, los cuales poseen características 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 información [Donoso y Sandoval, 2009]:

id_c nom_c num_p nodo_o nodo_d hora op_hora

Dónde:

• id_c: Identificador general del cliente.

• nom_c: Nombre del cliente.

• num_p: Número de pasajeros (acompañantes).

• nodo_o: Nodo origen de la petición.

• nodo_d: Nodo destino de la petición.

97

• hora: Hora deseada de recogida o llegada.

• op_hora: Opción de la hora del cliente.

98

Capítulo 8: Implementación

En este capítulo se realizará un análisis en base al cumplimiento de los diferentes objetivos del proyecto, evaluando en una primera instancia la creación e integración de las diferentes geometrías 3D en el entorno gráfico, luego se continuará con el análisis sobre la interfaz de usuario que posee el simulador de transporte, posteriormente se presentarán algunas mejoras relacionadas con la forma de visualizar el entorno gráfico, y finalmente se explicará el método de solución utilizado para implementar el sistema de rutas de los vehículos en el entorno.

8.1 Conexión entre el SMA y el Motor Gráfico

Para realizar la conexión entre el Sistema Multiagente y el motor gráfico 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 automática, se procesan y se envían al agente Manager3D mediante un mensaje ACL, luego a partir de la instancia del motor gráfico que se posee en dicho agente, se realiza una llamada a sus métodos públicos para poder informar los cambios que se han producido en el sistema, el cual finalmente procesa dicha información dentro del entorno gráfico y la representa por pantalla.

Generación de

Eventos SMA

Captura de

Eventos SMA

Recepción de

Eventos Agente

Manager3D

Recepción de Eventos

Motor Gráfico

Mediante sus Métodos

Generación de

Eventos Motor

Gráfico

Recepción de Eventos

Agente Manager3D

Mediante sus Métodos

Figura 8.1 Conexión entre SMA y el motor gráfico [Elab. Propia]


99

Por otro lado, se encuentra la captura de eventos por parte del motor gráfico, en donde se procesa dicha información en el mismo motor y se envía al agente Manager3D mediante los métodos públicos de captura que este posee (por lo que puede verse el proceso inverso de envía y captura de información descrito anteriormente). Luego de que el agente toma esa información, se genera el mensaje ACL con el receptor correspondiente (un vehículo o un cliente) y se le envía, siendo el resultado de esta acción capturada por el simulador y enviada al agente Manager3D nuevamente, repitiéndose de esta forma el primer flujo de acciones para representar en la interfaz 3D dichos eventos.

8.2 Desarrollo e Integración de Modelos 3D

Cada uno de los modelos necesarios para la interfaz 3D se ha desarrollado en su completitud, incorporándolo 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 vehículos y los clientes; por lo que cualquier otro modelo 3D solo está relacionado con el acabado estético 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 (geometría 3D), en donde se ubican las calles y paraderos de manera estática (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 intersección entre dos calles, etc., facilitando de esta forma el texturizado general del entorno.

Respecto a los vehículos (ver Figura 8.4), estos también se realizaron de forma estática, sin separar las geometrías relativas a las ruedas con el resto del vehículo. A pesar de no ser un proceso difícil de realizar e implementar, se optó por simplificar lo más posible las diferentes geometrías del entorno a fin de no afectar el rendimiento final de la aplicación, considerando además que esta se ejecuta en paralelo con el simulador de transporte, lo cual puede disminuir drásticamente la cantidad de frames presentados por segundo (fps).

Respecto a la implementación realizada mediante agentes, al momento de inicializar el agente Manager3D se han establecido las propiedades iniciales de la pantalla, las cuales son: título de la ventana, su resolución (800x600 pixeles), activación de la sincronización vertical, entre otros. Una vez finalizadas estas actividades, se procede a enviar la información del grafo y los vehículos obtenidos a partir de sus respectivos archivos de texto al motor, para posteriormente iniciar la ejecución de la aplicación, tal como se había diseñado en las secciones previas.

100

Figura 8.2 Diseño modelo ciudad 3D [Elab. Propia]

Algunas de las técnicas utilizadas por los motores gráficos mencionadas en el apartado 3.4 aplicadas a la interfaz, han sido: la utilización 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 creación de la luz ambiental, y luces direccionales para la luz solar; y finalmente la aplicación de LODs en la generación 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 técnicas de modelado presentadas en el apartado 4.1, el modelado poligonal ha sido la más utilizada, tanto en la creación de los edificios, como también en la creación de los vehículos, esto se debe principalmente a la estructura rígida que estas dos geometrías poseen. La técnica de modelado mediante splines fue utilizada para la creación de los clientes del sistema de transporte (ver Figura 8.5), pero únicamente para el diseño de la cabeza, ya que la parte restante se diseñó mediante el modelado poligonal. Hasta el momento no se ha utilizado la técnica de sculpting, debido a que no es de principal importancia el desarrollar modelos 3D con un acabado estético totalmente profesional (lo cual obviamente mejoraría considerablemente el acabado final de la interfaz).


101

Figura 8.3 Diseño modelo paradero 3D [Elab. Propia]

Figura 8.4 Diseño modelo vehículo 3D [Elab. Propia]



102

Cada uno de los vehículos y clientes se han cargado a partir de la información recopilada por el agente Manager3D, el cual, como se mencionó anteriormente, procesa dicha información y luego procede a enviársela al motor gráfico mediante la llamada de sus diversos métodos. 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 vehículos, 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 actualización para poder sincronizar la interfaz con las llamadas a métodos que está realizando el agente Manager3D.

El proceso de sincronización se logró mediante la pausa sucesiva de eventos como la creación de un cliente, la creación de un vehículo, la solicitud de un nuevo recorrido, entre otros; incorporando dichas pausas en bucles y métodos que son llamados sucesivas veces, como es el caso de los métodos de actualización que poseen las clases que heredan de la clase “TickerBehaviour”.

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


103

8.3 Interfaz Gráfica de Usuario del Simulador

Cabe mencionar que el tamaño de la pantalla se ha establecido de manera predeterminada como una ventana y no en pantalla completa, ya que existe una interfaz gráfica de usuario (GUI) desarrollada para el simulador de transporte de pasajeros, con la cual se puede obtener información más detallada sobre las tareas que están llevando a cabo los agentes del sistema en todo momento.

Figura 8.6 Panel de actualización 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 comunicación con el agente Manager3D, se ha extendido dicha GUI, añadiendo en esta nuevos paneles de datos. En la Figura 8.6 se puede observar el panel de actualización de la interfaz 3D, denominada “Interface 3D Panel”, en un comienzo muestra la información 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 habilitación de la sincronización vertical, etc.

La mayor parte de la captura de información del Sistema Multiagente y su asignación al panel de información 3D se sincronizó pausando ambos sistemas, de esta forma se puede observar una relación entre los datos presentados por el “Schedule Panel” y los datos presentados por la “Interface 3D Panel”, mejorando la presentación de la sucesiva información 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 botón 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 Asignación de Caminos

Ya que cada uno de los vehículos posee la capacidad de desplazarse por la ciudad, es necesario implementar algún método de seguimiento de rutas que se adecue a la información recibida del simulador, considerando además elementos propios de la interfaz, por ejemplo, la rotación del vehículo según 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 gráfico jMonkeyEngine permite la implementación de splines para la generación de rutas y la asignación 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 abstracción necesaria respecto a la utilización de vectores, simplificando en gran medida su comprensión y facilidad de implementación. En la Figura 8.8 se puede observar el modo de depuración del camino, siendo visible los nodos y conexiones entre dichos nodos, lo que permite que los diferentes vehículos puedan cambiar su dirección y sentido respecto a la ruta actual en que se encuentran, proceso realizado de forma automática por la instancia de la clase MotionPath al momento de asignar el vehículo a esa ruta.


106

Figura 8.9 Implementación del pathfinding [Elab. Propia]

En la Figura 8.9 se puede observar la implementación 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 continuación se describe mediante un código dicha implementación:

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 incorporación de los puntos se realiza mediante el método “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 método “enableDebugShape”.

4 3

2

1


107

Para asignar un vehículo 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 dirección del objeto al momento de seguir la ruta, siendo en este caso de manera total, es decir, el modificar la dirección y el sentido del vehículo de acuerdo a la dirección y sentido de la ruta. Otra característica que se verá afectada es la rotación de los vehículos, 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.Directio n. 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 vehículo, de esta forma, independiente de la ruta a la cual el vehículo se ha asignado, mantendrá la misma velocidad.

Finalmente se inicia el movimiento del vehículo en la ruta mediante la llamada del método “play” .

grafo_rutas [67].setPathSplineType(SplineType. Linear ); grafo_rutas [67].addListener(new MotionPathListener(){ public void onWayPointReach(MotionEvent control, int wayPointIndex){ if (control.getPath().getNbWayPoints() == wayPointInde x + 1){ //dentro se incorpora lo que se desea r ealizar con //el vehículo. } } });

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

108

8.5 Interfaz Gráfica 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 gráfico jMonkeyEngine. Este permite incorporar interfaces gráficas dentro de la ventana de la interfaz 3D, siendo totalmente compatibles con elementos propios del motor, como las geometrías que se encuentran dentro del entorno, siendo posible incluso el crear interfaces en los polígonos de dichas geometrías. En este proyecto, específicamente se ha hecho uso de las cajas de texto para mostrar cierta información, y submenús con opciones, los cuales se despliegan al momento de seleccionar algún cliente, vehículo o nodo de parada.

Figura 8.10 Menú desplegable de la GUI 3D clientes y vehículos [Elab. Propia]

En la Figura 8.10 y 8.11 se puede observar el submenú generado al momento de seleccionar un vehículo, un cliente o nodo de parada; los cuales se generan a partir de la selección de dicha entidad, esta selección se realiza mediante la utilización de la clase “ActionListener”, correspondientes a los métodos de entrada del mouse.

Permite establecer la cámara en primera

persona a la entidad seleccionada

Panel de información

Genera un evento de cancelación

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 información de los clientes de la GUI 3D [Elab. Propia]

En la Figura 8.12 se puede observar la generación del panel de información 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 gráfica de usuario Nifty GUI.

Identificador del cliente (otorgado por el motor gráfico)

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 código Java), siendo en este caso utilizado el último método, debido a la facilidad de uso que esta posee.

8.6 Modificaciones Anexas

Debido a la dificultad que implica el observar los vehículos y clientes en la ciudad producida principalmente por la utilización 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 transformación 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 través 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. También a dicho material se la ha desactivado la opción 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 vehículos, clientes y nodos de parada a través de los edificios. Esto claramente permite trabajar de manera mucho más fácil con la interfaz de Nifty GUI y el entorno gráfico.

Eliminado: h

112

Capítulo 9: Conclusiones

Con la presente memoria se espera haber entregado una visión lo suficientemente concreta respecto a los modelos e ideas presentadas, como también a la estructura de solución que se ha implementado hasta el momento. A continuación se detallan de forma estructurada las conclusiones obtenidas a partir del desarrollo de este proyecto.

9.1 Sobre los Diferentes Tópicos y su Integración

Se ha logrado comprender cada uno de los temas involucrados para el desarrollo de una aplicación en común. Respecto a la utilización de visualizadores tridimensionales, se han identificado algunas ventajas en su implementación sobre sistemas complejos, principalmente en la comprensión de elementos que interactúan internamente en un sistema.

Por otra parte, se ha analizado la gran utilidad que significa el uso de la tecnología de agentes en la resolución de problemas, en especial cuando el conjunto de elementos que interactúan en el sistema trabajan de forma distribuida, a velocidades muy altas, o incluso en paralelo. De esta forma, tanto la Visualización 3D como los Sistemas Multiagente otorgan una base para el desarrollo de aplicaciones robustas y completas, las cuales pueden comenzar desde la lógica resolutiva del problema a desarrollar, y llegar hasta la generación de interfaces tridimensionales interactivas para su comprensión.

En el caso de los sistemas flexibles de transporte, específicamente los de respuesta a demanda, existe una gran cantidad de elementos que interactúan entre sí, por lo que se genera cierta complicación en su comprensión, si además se considera su planteamiento mediante la utilización de la tecnología de agentes, se le incorporan muchas más características, terminando finalmente en un sistema bastante complejo. Al incorporar las características 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 asignación de vehículos, o mantener un ruteo de las diferentes posiciones en que se encuentran los clientes, etc.

9.2 Sobre los Objetivos Cumplidos

En consideración 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 metodología de trabajo escogida y cumplir con los tiempos propuestos en la fase de planificación del proyecto. A continuación se explican de forma generalizada cada uno de los pasos:

Eliminado: el presente informe

Eliminado:

113

1) El análisis general enfocado a los componentes del simulador de transporte que tienen directa relación con una posible representación en la interfaz gráfica, todo esto a fin de simplificar y mejorar la forma de representar la información relativa a ellos. Aquí se considera todo el proceso de análisis de los diferentes tópicos del proyecto y el establecimiento de la conexión que hay entre ellos.

2) Definición de la estructura general de la ciudad y los elementos que la componen, en la cual transitarán los diferentes vehículos, considerando además los nodos (paraderos) en donde estos puedan recoger o bajar clientes. Todo esto basado en un exhaustivo proceso de diseño, tanto del Sistema Multiagente como del motor gráfico.

3) Creación de los diferentes elementos 3D que componen la escena en su totalidad, para luego centrarse únicamente en la lógica que debe ser implementada.

4) Informar de los diferentes acontecimientos efectuados en el simulador de transporte al agente encargado de administrar la interfaz gráfica, permitiendo de esta forma procesar la información y adaptarla para su posterior representación.

5) Enviar la información procesada al motor gráfico, el cual genera los cambios necesarios tanto en los elementos que son visibles para el usuario (movimiento de un bus, desaparición de un cliente, generación de los edificios, etc.), y también los que se centran en la lógica de la interfaz (obtención de la próxima ruta a asignar al bus, ubicación 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 vehículos correspondientes, y luego enviar dicha información al administrador de la interfaz gráfica (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 utilización de rutas ya definidas por el motor gráfico para simplificar el proceso de implementación, lo que en general conlleva a una mejora bastante importante en relación a la funcionalidad del sistema, mejorando además la experiencia del usuario final.

Respecto al motor gráfico jMonkeyEngine (JME), gracias a su entorno de desarrollo basado en el IDE Netbeans, se han facilitado bastante los procesos de depuración e implementación 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 aplicación cada vez que se requiera. Además, no se han producido grandes inconvenientes en la integración del Sistema Multiagente basado en la plataforma de desarrollo de agentes JADE y las clases


114

definidas por JME, debido principalmente a la utilización en ambas plataformas del lenguaje de programación Java.

Debido a la naturaleza misma del proyecto, el diseño realizado de las pruebas se ha utilizado únicamente para validar las funcionalidades propuestas, por lo que no se ha realizado una sección que trate únicamente de la evaluación de resultados de las mismas.

9.3 Sobre el Trabajo Futuro

Como se mencionó anteriormente, el diseño de la ciudad y el conjunto de paraderos, edificios, veredas, entre otros; han sido pensados de manera estática, por lo que el Sistema Multiagente se adecúa 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 generación automática de todos los elementos que conforman la interfaz tridimensional.

Además, el entorno gráfico ha sido implementado en base a un simulador de transporte que hace uso del framework MADARP, por lo que podría considerarse una adaptación del visualizador tridimensional únicamente al framework, generando los elementos básicos 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, “Visualización 3D de Sistema Multiagente Aplicado al Problema de Transporte de Pasajeros”, Pontificia Universidad Católica de Valparaíso, Tesis de Grado de Magíster en Ingeniería Informática, 2009.

[Bauer et al., 2001] Bernhard Bauer, Jörg P. Müller, James Odell, “Agent UML: A Formalism for Specifying Multiagent Interaction”, Springer-Verlag, Berlín, 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.

[Canós et al., 2003] José H. Canós, Patricio Letelier, Mª Carmen, “Metodologías Ágiles en el Desarrollo de Software”, Universidad Politécnica de Valencia, Taller VIII Jornadas de Ingeniería del Software y Bases de Datos, JISBD, 2003.

[Castillo et al., 2010] Luis F. Castillo, Oscar H. Franco, Jaime A. Giraldo, “Agentes basados en Ontologías para la Web Semántica”, Universidad Nacional de Colombia, Quinto Congreso Colombiano de Computación, 2010.

[Cordeau y Laporte, 2002] Jean-François 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, año Libro: Autores, titulo, editorial, año

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 Informática, 2005.

[Donoso y Sandoval, 2009] Makarena Donoso, Daniel Sandoval, “Desarrollo de un Sistema Multiagente para el Dynamic Dial-a-Ride Problema (D-DARP), utilizando Tecnología de Agentes”, Pontificia Universidad Católica de Valparaíso, Proyecto de Título en Ingeniería de Ejecución Informática, 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 tecnologías de hardware gráfico en el apoyo al realismo en entornos virtuales arquitectónicos”, Universidad de Colima, Colima, México, Tesis Posgrado Telemática, 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.

[Gómez et al., 1999] Pedro Gómez, Marco Gómez, 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, “Gráficos 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

[Hípola y Vargas-Quesada, 2005] Pedro Hípola, Benjamín Vargas-Quesada, “Agentes inteligentes: definición y tipología. Los agentes de información”, Revista internacional científica y profesional, 2005.

[Keller, 2011] Erick Keller, “Introducing Zbrush 4”, SYBEX, 2011, pp 15-30.

[Maroto, 2005] Joaquín Maroto Ibáñez, “Metodología para la generación de entornos virtuales distribuidos y su aplicación a simuladores de conducción”, Universidad Politécnica de Madrid, Tesis Doctoral en Ingeniería Mecánica, 2005.

[Mas, 2005] Ana Mas, “Agentes Software y Sistemas Multi-Agente: Conceptos, arquitecturas y aplicaciones”, 2005, pp 10-160.

[Müller et al., 1995] Müller, J. P., Pischel, M. and Thiel, M, “Modelling reactive behaviour in vertically layered agent architectures”, Lecture Notes in Computer Science, 1995.

[Navarra y Martínez, 2006] Pablo Navarra, José Martínez, “Agentes inteligentes en la búsqueda y recuperación de información”, 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.

[Rodríguez et al., 2003] Alonso Rodríguez, Campillo Tomico, Pérez Crespo, “Radiosidad: Gráficos y Visualización 3D”, Universidad Rey Juan Carlos, Escuela Superior de Ciencias Experimentales y Tecnología, 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 Simón, 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 4th 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, Página Web: http://www.ambysoft.com/unifiedprocess/agileUP.html, 2005.

[URL 2, 2010] Agente RAE, Página 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, Página Web: http://blogs.aerys.in/jeanmarc-leroux/tag/quake-3/, 2011.

[URL 5, 2000] 3D Pipeline, Página Web: http://www.anandtech.com/show/558/3, 2000.

[URL 6, 2009] Classical LOD Algorithms, Página Web: http://habib.wikidot.com/techniques, 2009.

[URL 7, 2012] Radiosidad, Página Web: http://wiki.blender.org/index.php/Doc:ES/2.4/Manual/Lighting/Radiosity, 2012.

[URL 8, 2012] Irrlicht, Página Web: http://irrlicht.sourceforge.net/, 2012.

[URL 9, 2012] Panda3D, Página Web: http://www.panda3d.org/, 2012.

[URL 10, 2012] Ogre3D, Página Web: http://www.ogre3d.org/, 2012.

119

[URL 11, 2012] Crystal Space, Página Web: http://www.crystalspace3d.org/main/Main_Page, 2012.

[URL 12, 2012] Unity3D, Página Web: http://unity3d.com/, 2012.

[URL 13, 2012] UDK, Página Web: http://udk.com/, 2012.

[URL 14, 2012] jMonkeyEngine, Página Web: http://jmonkeyengine.com/, 2012.

[URL 15, 2006] Box Modeling, Página Web: http://wiki.cgsociety.org/index.php/Modeling_a_foot, 2006.

[URL 16, 2004] NURB Modeling, Página Web: http://www.3dmax-tutorials.com/_2_Rail_Sweep_Surface.html, 2004.

[URL 17, 2011] Perfiles de Splines, Página Web: http://www.etereaestudios.com/training_img/subd_tips/introduccion.htm, 2011.

[URL 18, 2011] Sculpting, Página Web: http://estab1986.com/blog/tag/hard-surface-sculpting, 2011.

[URL 19, 2008] Texturizado, Página Web: http://ptex.us/ptexpaper.html, 2008.

[URL 20, 2009] Texturas Procedurales, Página Web: http://www.oocities.org/valcoey/texturas_procedurales.html, 2009.

[URL 21, 2012] Vertex Paint, Página Web: http://wiki.blender.org/index.php/Doc:2.4/Manual/Materials/Vertex_Paint, 2012.

[URL 22, 2009] Vertex Paint, Página Web: http://www.blender.org/development/release-logs/blender-256-beta/brushes/, 2009.

[URL 23, 2006] UV Map, Página Web: http://www.members.shaw.ca/nickyart/Comp/Camel.htm, 2006.

[URL 24, 2012] 3D Studio Max, Página Web: http://usa.autodesk.com/3ds-max/, 2012.

[URL 25, 2012] Maya, Página Web: http://usa.autodesk.com/maya/, 2012.

[URL 26, 2012] Google SketchUp, Página Web: http://sketchup.google.com/intl/es/, 2012.

[URL 27, 2012] Cinema 4D, Página Web: http://www.maxon.net/es/products/cinema-4d-studio.html, 2012.

[URL 28, 2012] Zbrush, Página Web: http://www.pixologic.com/home.php, 2012.

[URL 29, 2012] Blender, Página Web: http://www.blender.org/, 2012.

Anexos

A: Ontología 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 Ontología del dominio proyecto relacionado [Donoso y Sandoval, 2009]

Con formato: Inglés (EstadosUnidos), No revisar la ortografíani la gramática

Documents

Informe Final Proyecto de Título MARZO 2013 Rev Ccfx