You are on page 1of 62

Gua de estudio de la asignatura: Sistemas Informticos II del curso 2012-2013

Jos Ramn lvarez Snchez Dpto. de Inteligencia Articial - ETSI Informtica - UNED

Versin de 2012-10-01 (la versin actualizada estar siempre en el curso virtual de la asignatura)

Gua de estudio de la asignatura: Sistemas Informticos II del curso 2012-2013 2012-2013 Jos Ramn lvarez Snchez (Dpto. Inteligencia Articial - UNED). Este material ha sido redactado especcamente para la asignatura de Sistemas Informticos II, en la titulacin Ingeniero Informtico de la UNED, por su equipo docente. Quedan prohibidas, sin la autorizacin de los titulares del Copyright, bajo las sanciones establecidas en las leyes, la reproduccin total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la reprografa y el tratamiento informtico, y la distribucin de ejemplares de ella mediante venta, alquiler o prstamo pblicos. Se autoriza expresamente a los alumnos matriculados en la UNED la descarga, copia e impresin de este material nicamente para su uso personal. Tambin queda autorizada su distribucin por la ETSI Informtica de la UNED en los CDROM que edite para acompaar las guas de curso o el DVD que las sustituya, as como a cualquier otro medio ocial de distribucin proporcionado por la UNED para sus alumnos. La ltima versin ocial, en diferentes formatos, se podr obtener desde el curso virtual de la asignatura que la UNED pone a disposicin de los alumnos matriculados en ella. La composicin tipogrca de este texto se ha realizado por su autor, utilizando LyX y LaTeX, as como su conversin a HTML mediante eLyXer.

ndice general
Lista de cambios y erratas corregidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gua de estudio de la asignatura Presentacin, objetivos y contexto Esquema y resumen de contenidos Material y medios de estudio . . . Evaluacin . . . . . . . . . . . . .
V VII

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. VII . VIII . IX . X 1 2 2 2 3 3 3 4 4 4 5 9 10 10 10 11 11 11 12 12 12 13 14 14 17 17 18 18 18 19 23 24 24 25

1. Adquisicin y representacin del conocimiento 1.1. rboles, grafos y redes asociativas . . . . . 1.1.1. rboles y grafos . . . . . . . . . . 1.1.2. Redes asociativas . . . . . . . . . . 1.2. Lgica y reglas . . . . . . . . . . . . . . . 1.2.1. Tipos de lgicas . . . . . . . . . . 1.2.2. Reglas . . . . . . . . . . . . . . . . 1.3. Marcos, guiones y ontologas . . . . . . . . 1.3.1. Marcos y guiones . . . . . . . . . . 1.3.2. Ontologas . . . . . . . . . . . . . Ejercicios y actividades . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

2. Tcnicas de bsqueda en espacio de posibles soluciones 2.1. Exploracin exhaustiva (bsqueda bsica) . . . . . . . . . . . . . 2.1.1. Esquema de produccin (bsqueda en espacio de estados) 2.1.2. Esquema de reduccin (divisin en subproblemas) . . . . 2.2. Bsqueda basada en conocimiento heurstico . . . . . . . . . . . 2.2.1. Estrategia irrevocable: mtodo del gradiente . . . . . . . . 2.2.2. Exploracin de alternativas . . . . . . . . . . . . . . . . . 2.2.3. Bsqueda con adversarios . . . . . . . . . . . . . . . . . 2.3. Bsqueda hbrida: computacin evolutiva . . . . . . . . . . . . . 2.3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3. Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Sistemas de razonamiento o inferencia basados en reglas y en casos 3.1. Inferencia basada en reglas . . . . . . . . . . . . . . . . . . . . . 3.1.1. Tipos de inferencia . . . . . . . . . . . . . . . . . . . . . 3.1.2. Reglas con incertidumbre . . . . . . . . . . . . . . . . . 3.1.3. Reglas con marcos o guiones . . . . . . . . . . . . . . . . 3.2. Razonamiento basado en casos . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

4. Agentes inteligentes y robtica 4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Agentes software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Robots mviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III

IV

Sistemas Informticos II

A. Gua de la prctica obligatoria A.1. Objetivos de la prctica . . . . . . . . . . . . . . . . . . . A.2. Material y software . . . . . . . . . . . . . . . . . . . . . A.2.1. Necesario . . . . . . . . . . . . . . . . . . . . . . A.2.2. Recomendado . . . . . . . . . . . . . . . . . . . . A.2.3. Opcional . . . . . . . . . . . . . . . . . . . . . . A.3. Elaboracin y desarrollo del programa . . . . . . . . . . . A.3.1. Edicin, compilacin y ejecucin . . . . . . . . . A.3.2. Descripcin de las funciones bsicas . . . . . . . . A.3.3. Diseo del programa para la prctica . . . . . . . . A.3.4. Detalles sobre restricciones y formas de soslayarlas A.4. Condiciones del programa nal . . . . . . . . . . . . . . . A.4.1. Ubicacin y nomenclatura . . . . . . . . . . . . . A.4.2. Limitaciones y restricciones . . . . . . . . . . . . A.4.3. Capacidades mnimas . . . . . . . . . . . . . . . . A.5. Memoria de la prctica . . . . . . . . . . . . . . . . . . . A.6. Forma y plazo de entrega . . . . . . . . . . . . . . . . . . A.6.1. Formato del chero a enviar . . . . . . . . . . . . A.6.2. Medio de envo del chero . . . . . . . . . . . . . A.6.3. Plazo de envo . . . . . . . . . . . . . . . . . . . A.7. Evaluacin de la prctica . . . . . . . . . . . . . . . . . . A.7.1. Mnimo para superar la prctica . . . . . . . . . . A.7.2. Puntos de competicin . . . . . . . . . . . . . . . A.7.3. Puntos extra del equipo docente . . . . . . . . . . Bibliografa

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

29 29 30 30 31 32 32 32 34 37 40 41 41 41 43 43 44 45 45 46 46 46 47 48 49

Lista de cambios y erratas corregidas

Lista de cambios y erratas corregidas


Se listan a continuacin los cambios realizados en cada versin respecto a la anterior (orden de ms reciente a ms antigua)1 de esta gua. Solamente se incluyen aqu los cambios o modicaciones signicativos, relevantes respecto al contenido. No se incluyen en esta lista las erratas tipogrcas, ortogrcas y de puntuacin nosignicativas ya corregidas que no induzcan a error ni afecten a la comprensin.

2012-10-01 Versin inicial del curso 2012-2013


Primera versin al inicio del curso disponible en el curso virtual de la asignatura.

1 En

el curso virtual de la asignatura siempre estar accesible la ltima versin ms moderna en PDF y HTML.

VI

Sistemas Informticos II

Gua de estudio de la asignatura


Equipo docente: Jos Ramn lvarez Snchez Asignatura: Sistemas Informticos II Cdigo: 55-503-1 (5 curso de la titulacin: Ingeniero Informtico) Breve descripcin: Metodologa de anlisis, conguracin, diseo, gestin y evaluacin de sistemas informticos. Proyectos de sistemas informticos.

Presentacin, objetivos y contexto


El objetivo principal de esta asignatura es desarrollar un conjunto de enseanzas de carcter aplicado sobre el anlisis, conguracin, diseo, gestin y evaluacin de sistemas informticos. Dada la extensin del campo y la existencia de otras dos asignaturas sobre Sistemas Informticos dedicados a aspectos generales (Sistemas Informticos I) y la aplicacin de la metodologa de orientacin a objetos (Sistemas Informticos III), en esta asignatura haremos nfasis en la orientacin a los Sistemas Basados en Conocimiento (SBCs), que son una parte importante de los sistemas informticos. Este objetivo general, considerada esta asignatura como un laboratorio de desarrollo de SBCs, se puede desglosar en los siguientes objetivos concretos: Aspectos prcticos en el anlisis de especicaciones y tcnicas de adquisicin del conocimiento. Conocimiento de los aspectos prcticos asociados a los entornos de desarrollo de SBCs. Aplicacin de las tcnicas y mtodos de validacin y evaluacin de SBCs a casos concretos. Estos objetivos en general se pueden extender hacia las tcnicas y los procesos de desarrollo o construccin de los SBCs a travs de herramientas concretas y adquirir los conocimientos para la aplicacin o uso de los entornos de SBCs y de esas herramientas o tcnicas de construccin. Para conseguir estos objetivos se presentarn en cada tema las tcnicas y herramientas relacionadas con diferentes aspectos de los SBCs y la Inteligencia Articial (IA) en general. Las tareas de alto nivel en la IA como son percepcin, razonamiento, aprendizaje, planicacin o decisin se construyen con otras tareas ms bsicas como son la representacin, bsqueda y clasicacin. Es en estas ltimas tareas en las que nos centraremos en relacin con los aspectos prcticos de los SBCs dentro de esta asignatura. El espectro de aplicaciones y bibliotecas para los diferentes mtodos usados en los SBCs es muy amplio y por lo tanto el estudio realizado en esta asignatura estar limitado a algunos de los ms representativos en cada caso, aunque se intentarn indicar otros en las secciones de extensin de conocimientos correspondientes.

Contexto acadmico previo


Para el seguimiento eciente de esta asignatura se recuerda que el alumno ha cursado previamente la asignatura Inteligencia Articial e Ingeniera del Conocimiento en el segundo ciclo, e incluso puede haber cursado (en nuestro plan de estudios, o tiene los conocimientos equivalentes) la asignatura optativa de primer ciclo Sistemas Basados en el Conocimiento I. Es decir, el alumno debe conocer los aspectos metodolgicos bsicos para el desarrollo de SBCs, desde la fase inicial del modelado conceptual hasta la implementacin y evaluacin. Esa asignatura de Sistemas Informticos II es, en cierto modo, una continuacin natural hacia los aspectos
VII

VIII

Sistemas Informticos II

prcticos de la asignatura Inteligencia Articial e Ingeniera del Conocimiento y de otras materias previas relacionadas con ella. Tal como ya se ha mencionado antes, previamente a esta asignatura se cursa otra, Sistemas Informticos I de 4 curso, que proporcionar una buena parte de los conocimientos necesarios (programacin en entornos Java) para la ejecucin con xito de la prctica obligatoria de esta asignatura. Tambin pueden tener alguna inuencia, aunque en menor grado, las asignaturas relacionadas con la Ingeniera de Software que se imparten en cuarto curso, Anlisis, Diseo y Mantenimiento del Software y Anlisis y Gestin del Desarrollo del Software, respecto a la aplicacin prctica de anlisis de especicaciones y al mantenimiento, gestin y desarrollo de aplicaciones informticas. Adicionalmente, otras asignaturas del primer ciclo ms relacionadas con la programacin en general, o ms especcas como las optativas Programacin Concurrente, Programacin Declarativa y Programacin Orientada a la Inteligencia Articial en el primer ciclo de las titulaciones de Ingeniero Tcnico en Informtica de la UNED (o sus equivalentes en otras universidades), deben proporcionar al alumno unas buenas bases sobre programacin y pueden encontrar su aplicacin en esta asignatura.

Contexto acadmico posterior


Los estudios de esta asignatura tienen inuencia sobre los temas tratados en otras asignaturas posteriores. En particular con la obligatoria Sistemas Informticos III, ms las optativas Robtica Perceptual, Conexionismo, Procesamiento y Aplicaciones del Lenguaje Natural, Aprendizaje y Personalizacin del Software, Diseo de Sistemas de Trabajo Cooperativo (CSCW), Tcnicas Avanzadas de Razonamiento y naturalmente con el Proyecto de Fin de Carrera.

Esquema y resumen de contenidos


Dado el carcter eminentemente prctico de esta asignatura, los contenidos del temario estn orientados a la descripcin de aplicaciones, utilidades y bibliotecas de programacin (libreras) relacionadas con los Sistemas Basados en el Conocimiento (SBCs) y con la Inteligencia Articial (IA) en general. Junto con estas descripciones de aspectos prcticos, en cada tema se incluye una pequea introduccin, a modo de recordatorio, de los conocimientos tericos que se aplican. Los conocimientos tericos relativos a los SBCs (como ya se ha comentado en el apartado contexto previo) deben haber sido estudiados en profundidad en otras asignaturas anteriores. A continuacin exponemos un resumen de los temas que componen el contenido de la asignatura que se expandir ms adelante. Estos temas se corresponden con los objetivos presentados anteriormente y estn relacionados con los aspectos prcticos en las tareas bsicas de la IA para representacin, bsqueda y clasicacin, que se utilizan en los SBCs. En el primer tema se abordan las cuestiones prcticas sobre anlisis de especicaciones y tcnicas de adquisicin del conocimiento. En los temas 2 y 3 se tratan los aspectos prcticos asociados a los entornos de desarrollo de SBCs, y el ltimo tema se enfoca en la aplicacin prctica de los SBCs en los paradigmas de la IA como los agentes inteligentes o la robtica. En el apndice nal se incluye la gua de la prctica obligatoria de la asignatura.

Esquema:
Tema 1: Adquisicin y representacin del conocimiento rboles, grafos y redes asociativas Lgica y reglas Marcos, guiones y ontologas Tema 2: Tcnicas de bsqueda en espacio de posibles soluciones Recorrido exhaustivo Bsqueda basada en conocimiento heurstico Bsqueda hbrida: computacin evolutiva

Gua de Estudio de la Asignatura

IX

Tema 3: Sistemas de razonamiento o inferencia basados en reglas y en casos Inferencia basada en reglas Razonamiento basado en casos Tema 4: Agentes inteligentes y robtica Agentes software Robots mviles Apndice A: Gua de la prctica obligatoria

Material y medios de estudio


Todo el material de estudio obligatorio y necesario se detallar en esta Gua Didctica (o Gua de Estudio) especca elaborada por el equipo docente. Esta gua contiene las indicaciones de los materiales adecuados para preparar la asignatura, as como material complementario necesario. En especial, se incluye un apndice (pg. 29) con la descripcin y condiciones para desarrollar la prctica obligatoria, que es recomendable leer (e intentar resolver) simultneamente a los temas de contenido terico (que son mayormente de recordatorio). La ltima versin de esta Guia Didctica estar disponible a travs del curso virtual de la asignatura.

Estructura de esta Gua Didctica y material de estudio


En los siguientes captulos de esta gua de estudio se detallan los contenidos con la informacin que el alumno de educacin a distancia necesita para poder estudiar la asignatura. Al principio de cada captulo se incluye un Tutorial previo con los elementos que describen el contexto, conocimiento previo, objetivos y gua de estudio para ese captulo. Tanto el Tutorial previo como el Tutorial posterior en cada captulo van sin numerar y adems en la versin en PDF tienen una letra de tipografa distinta (helvtica o sans serif) para que se distingan de los contenidos en s mismos que s van numerados por niveles (y que estn en letra normal roman o serif en la versin en PDF). A lo largo de este material se hacen referencias muy habitualmente a los libros que el alumno ya ha utilizado al preparar la asignatura Inteligencia Articial e Ingeniera del Conocimiento de cuarto curso: [MDGBD95] y [FGGBMM98]. Estos libros cubren la mayor parte del temario terico, y se complementarn cuando sea necesario con otro material incluido directamente en esta gua o con referencias a otros materiales accesibles a travs de Internet. En esta gua los contenidos tericos que se recomienda repasar en cada captulo se sustituirn por la referencia (entre corchetes como [MDGBD95, sec. ... y cap ...]) a los apartados de los libros o referencias externas (consultar correspondencia en la bibliografa de la pg. 49), o bien se incluirn desarrollados directamente en esta gua si no existe una correspondencia directa con un libro. Al nal de cada captulo se incluye en esta gua un Tutorial posterior (con la misma tipografa de letra que el Tutorial previo) que contiene un resumen, en algunos casos puede contener ejercicios o actividades propuestas, para que el alumno pueda comprobar si ha logrado los objetivos del captulo, y tambin informacin adicional para la extensin de conocimientos para los alumnos interesados en profundizar en el tema, junto con referencias alternativas sobre los mismos contenidos, cuando sea aplicable. Adicionalmente, en las referencias correspondientes a cada apartado suelen encontrarse tambin ejercicios relacionados con el tema. En especial, el libro [FGGBMM98] es de problemas resueltos, por lo que puede proporcionar mayor refuerzo a los recordatorios del contenido terico. Para la prctica obligatoria ser necesario instalar y utilizar un software que se indica en el apndice correspondiente (ver pg. 29). Es conveniente que se empiece cuanto antes a probar el programa para resolver la prctica con tiempo suciente (ver apartado de Evaluacin en la pg. X). Al nal de esta gua didctica se incluye una recopilacin de todas las referencias bibliogrcas (recomendadas o referidas en el material, con la abreviatura de autores y ao entre corchetes).

Sistemas Informticos II

Medios Adicionales
Adicionalmente a esta gua, el alumno dispondr de los medios de comunicacin habituales con su Profesor Tutor en el Centro Asociado, o a travs del Curso Virtual de la UNED en la direccin http://www.innova. uned.es/dotlrn/classes/1102/555031/sistemasinformaticosii/, y tambin con el Equipo Docente en la Sede Central (en las direcciones, telfonos y horarios indicados en la Gua de Curso). Esto se complementa con los canales de comunicacin y recopilacin de informacin tanto en soporte fsico (DVD) como en lnea2 a travs del curso virtual de la asignatura. En todos estos medios se incluir la informacin particular de referencias y contenidos que se detallan en los captulos de esta gua, con la ventaja adicional de que en los medios en lnea los enlaces de direcciones en Internet y otros materiales se irn ampliando y actualizando ms frecuentemente. Adems de las referencias bibliogrcas que aparecen en los libros bsicos [MDGBD95, FGGBMM98] ya indicados anteriormente, y del material incluido en esta gua, y aparte de otros libros o materiales posiblemente ya utilizados para asignaturas de la lnea de Inteligencia Articial en cursos anteriores, tambin se recomiendan como bibliografa complementaria de consulta general los libros de Russel y Norvig [RN96], de Rich y Knight [RK94] y de Nilsson [Nil01]. En especial, el libro [RN96], del cual tambin hay una traduccin al castellano de la 2 edicin (2003, Pearson Ed.), tiene asociada una pgina de informacin en internet donde, aparte de enlaces relacionados muy interesantes, los autores mantienen todo el cdigo fuente (versiones en LISP, Python, Java, Prolog y C++) de los algoritmos de ejemplo que se usan en el libro http://aima.cs.berkeley.edu/code.html. Estos ejemplos pueden resultar muy ilustrativos de forma prctica sobre los temas tratados en esta asignatura. De uno de los mismos autores (Norvig), hay un libro anterior [Nor92] que est ms orientado a los aspectos clsicos de la IA en LISP, del cual tambin mantiene pgina web con los fuentes de los ejemplos del libro http://www.norvig.com/paip.html. En el apndice dedicado a la gua de la prctica obligatoria se incluirn tambin algunas referencias a material de programacin en lenguaje Java que posiblemente tambin se hayan utilizado ya en la asignatura anterior Sistemas Informticos I.

Evaluacin
Dado el perl de la asignatura, la evaluacin de la misma se efectuar mediante dos pruebas: una presencial de tipo terico y otra de carcter prctico a distancia. Para superar la asignatura completa debern aprobarse cada una de las partes (terica y prctica) de forma independiente en el mismo curso. En caso de superar ambas partes, la nota nal de la asignatura estar compuesta por un 40 % de la nota de la prueba terica ms un 60 % de la nota de la prueba prctica. Mientras alguna de las dos partes est suspensa o no presentada, la nota total ser de suspenso, que se indicar en listado de calicaciones con una nota simblica especial (como por ejemplo: 0,4 0,6). La nota obtenida en cualquiera de las dos pruebas superadas en la convocatoria normal (Febrero) se mantendr hasta la convocatoria extraordinaria (Septiembre) del curso actual, nunca para cursos posteriores. Justo con las notas mnimas requeridas para aprobar cada una de las partes (como se detalla en los dos apartados siguientes), es decir 6,5 puntos en la prueba presencial y 4 puntos en la prueba prctica, la nota global resultante, al aplicar los porcentajes indicados antes, sera de aprobado con un 5 (= 40 % 6,5 + 60 % 4).

Prueba Presencial
La evaluacin de la componente terica de la asignatura se efectuar mediante la realizacin de una prueba de carcter presencial de una hora de duracin en las fechas y locales habilitados por la UNED en cada Centro Asociado. No se permitir la utilizacin de ningn material de consulta ni calculadoras durante la realizacin de esta prueba. La prueba presencial es de tipo objetivo (test) que incluir cuestiones terico-prcticas sobre aspectos fundamentales de la asignatura (slo sobre las secciones de contenidos en cada tema de esta Gua Didctica, los
2 La antigua pgina web http://www.ia.uned.es/asignaturas/si2/ propia de la asignatura, que puede aparecer mencionada en algunas versiones de la Gua de Curso, ha sido sustituida por los correspondientes contenidos en el curso virtual de la asignatura.

Gua de Estudio de la Asignatura

XI

apartados de Extensin de Conocimientos no se incluyen en ningn caso) y, principalmente, sobre conocimientos especcos de la prctica obligatoria que se ha realizado en el presente curso acadmico (ver apndice A). Cada pregunta tendr 4 posibles respuestas de las cuales slo una es la correcta. Todas las preguntas tendrn la misma puntuacin que ser proporcional al nmero de preguntas para normalizar la nota de 0 a 10. Cada respuesta incorrecta descontar la mitad de la puntuacin de una correcta. Las preguntas en blanco no aaden ni descuentan puntos. Para superar la prueba presencial se requiere una nota mnima de 6,5 puntos.

Prueba Prctica
El alumno debe realizar con carcter obligatorio un trabajo prctico individual (no se aceptan grupos) segn las instrucciones, condiciones, requisitos y especicaciones dados en el Apndice A (pg. 29) de esta Gua Didctica. La prctica debe ser realizada por el alumno por sus propios medios durante el cuatrimestre y se enviar para su evaluacin al equipo docente en la forma y plazo indicados tambin en el mismo Apndice A. Se recomienda comenzar cuanto antes a instalar y probar el software necesario para la prctica. En la calicacin de la prueba prctica se valorarn, principalmente, los aspectos de funcionalidad, eciencia, originalidad y adecuacin metodolgica de la solucin aportada tanto en la parte de software como en la memoria descriptiva correspondiente. La nota de la prueba prctica ser de 0 a 10, siendo necesario como mnimo un 4 para superarla. Es muy importante que el alumno lea completamente las instrucciones sobre la realizacin de la prctica, pues la evaluacin de la misma se realizar siguiendo exactamente las indicaciones dadas en el Apndice A.7 (pg. 46). En algunos captulos puede haber propuestas para realizar otras prcticas por el propio alumno, estas actividades o prcticas adicionales sern totalmente voluntarias (y que por tanto no podrn ser tenidas en cuenta para la puntuacin de la nota nal), aunque se recomienda al alumno su realizacin para ayudarle a una mejor comprensin de los temas. Solamente es obligatoria la realizacin y entrega en plazo de la prctica indicada en el Apndice A de esta Guia Didctica.

XII

Sistemas Informticos II

Tema 1

Adquisicin y representacin del conocimiento


Tutorial previo
Introduccin
Uno de los aspectos esenciales en la Ingeniera del Conocimiento y la Inteligencia Articial que se presentan en las primeras fases de la resolucin de un problema es la representacin del conocimiento del problema. Aunque cada tipo de mtodos utiliza unas formas de representacin caracterstica, podemos encontrarnos algunas representaciones que son comunes a bastantes mtodos. Las formas de representacin ms sencillas y bsicas son tambin las que ms se repiten. En este tema recordamos los rboles, grafos, redes, lgica, reglas, bases de datos, marcos, guiones y ontologas.

Relacin con otros temas


En este tema se tratan los mtodos de representacin utilizados en IC e IA, y por tanto se harn referencias a ellos desde los otros temas posteriores. Es importante conocer estas tcnicas de representacin, pues la nomenclatura usada est en la base de muchas descripciones de algoritmos o mtodos de resolucin de problemas.

Objetivos del tema


Lo ms importante de los medios representacin es conocer su existencia y la nomenclatura correspondiente, puesto que sern necesarios para posteriores temas. Tambin es interesante conocer cules son las herramientas existentes adecuadas para su manejo o utilizacin. El objetivo de este tema es recordar las principales formas de representacin en IA, ya estudiadas en asignaturas anteriores.

Gua de estudio y esquema


Es conveniente realizar una lectura inicial del tema para comprobar cules son los aspectos que se deben conocer en el mismo. Posteriormente, se debe acudir a repasar los conceptos y mtodos, ya estudiados previamente y que sea necesario recordar, a travs de las referencias dadas en cada apartado o en la bibliografa que se us en las asignaturas previas en las cuales se hayan estudiado. El tema se divide en tres partes: rboles, grafos y redes asociativas Lgica y reglas Marcos, guiones y ontologas

Adquisicin y representacin del conocimiento

1.1.
1.1.1.

rboles, grafos y redes asociativas


rboles y grafos

Las estructuras ms inmediatas usadas en la representacin de conocimiento son los rboles, como caso particular de los grafos. Se estudian en forma genrica dentro de las asignaturas de programacin y de estructuras de datos, puesto que son la base de muchos algoritmos. La representacin en un rbol es de tipo jerrquico y requiere que exista al menos un tipo de elemento base repetido, llamado nodo, y al menos un tipo de relacin entre los nodos, que se identica con los arcos. En los rboles la relacin es implcitamente dirigida (de padre a hijo) y normalmente sin ciclos (siempre se dirige hacia nodos no conectados anteriormente). Los grafos son un caso ms general, en el cual tambin tenemos nodos (pueden ser de varios tipos) y relaciones (tambin de diferentes clases) pero sin ninguna restriccin en las relaciones ni su direccin (incluyendo la relacin reexiva), incluso se consideran en algunos casos los nodos aislados (sin conexiones). La informacin almacenada o representada puede ir asociada tanto a los nodos como a los arcos, aunque siempre hay una componente relacional en esa representacin. La nomenclatura y caractersticas ms habituales de la representacin en grafos se encuentran en [MDGBD95, sec. 3.2.1], donde se usan en especial en relacin con la representacin de problemas de bsqueda aunque se pueden aplicar a cualquier representacin donde tengamos algn tipo de relacin entre elementos. Existen muchas herramientas, bibliotecas y entornos para utilizar (calcular, visualizar o manipular) grafos y rboles como estructuras de representacin. En el apartado extensin de conocimientos (pg. 5) se mencionan algunas de las ms interesantes gratuitas o de libre distribucin. Para una aplicacin prctica es conveniente utilizar aquellas que proporcionen las operaciones bsicas: asociacin de informacin a nodos o arcos, recorrido de caminos (profundidad o extensin), bsqueda de caminos mnimos, presentacin o visualizacin, edicin y modicacin, etc.

1.1.2.

Redes asociativas

Las redes asociativas son una forma particular de grafos (en muchos casos rboles), donde cada nodo representa un concepto o proposicin y los arcos representan diferentes tipos de relaciones o asociaciones entre los conceptos mencionados. Hay varios tipos de redes asociativas, como las redes relacionales, las redes proposicionales, las redes de clasicacin y las redes causales. Las redes relacionales (a veces tambin se llaman grafos relacionales) intentan representar los conceptos identicados con palabras o trminos individuales y las asociaciones son relaciones semnticas o jerrquicas entre las palabras. Ejemplos de redes relacionales son el modelo de memoria semntica de Quillian y los grafos de dependencia conceptual de Schank. En las redes proposicionales se expresan relaciones globales entre sintagmas, clusulas, frases o prrafos que se ubican en los nodos. Las relaciones suelen expresar caractersticas del lenguaje natural. Como ejemplo de redes proposicionales podemos citar las redes de Shapiro y los grafos de Sowa. Las redes de clasicacin forman jerarquas entre conceptos estableciendo una relacin de orden parcial sobre los nodos. Este orden parcial y la jerarqua correspondiente tienen especial relevancia cuando se asocian con la herencia de propiedades dando lugar a sistemas taxonmicos. Este tipo de redes est muy relacionada (incluso en algunos casos forma parte de ellos) con los marcos, guiones u ontologas que se tratan en el apartado 1.3. En los modelos de redes causales los nodos representan variables (medibles, observables o intermedias) y los arcos corresponden a relaciones de inuencia (suele ser una relacin de causalidad). Estos modelos se utilizan en problemas de diagnstico (medicina, averas en aparatos mecnicos o electrnicos, etc.) y son las ms interesantes desde un punto de vista prctico y de aplicacin. Las redes causales se utilizaron por primera vez en el sistema experto CASNET para diagnstico mdico (glaucoma). Un caso particular muy extendido e interesante son las redes Bayesianas, en las cuales los nodos contienen informacin probabilstica (probabilidades condicionadas para los posibles valores de las variables que representa el nodo) y las relaciones entre nodos expresan causalidad con independencia probabilstica. Las descripciones ms detalladas de las redes asociativas que se han indicado aqu se pueden encontrar en [MDGBD95, cap. 7] y [FGGBMM98, sec. 5.2]. Existe otro tipo de representacin similar a los grafos, las redes

1.2 Lgica y reglas

neuronales en particular y los sistemas conexionistas en general, aunque en este caso los nodos y conexiones representan clculos o tienen funciones asignadas, que se tratan en el tema 4 de esta gua.

1.2.
1.2.1.

Lgica y reglas
Tipos de lgicas

La lgica es la formulacin matemtica bsica de la inferencia en Inteligencia Articial ya que sienta las bases, o incluso es un requisito, de muchos de sus mtodos de resolucin. La lgica nos permite representar de manera formal las descripciones del lenguaje natural. La gran ventaja de la lgica para su aplicacin en la IA es precisamente el formalismo que la dene. Este formalismo es ideal para hacer computable el conocimiento, puesto que da una denicin exacta y concisa de lo que se representa, y al mismo tiempo permite su tratamiento automatizado. Segn la amplitud, riqueza y capacidad de expresin del formalismo utilizado, nos encontramos con diferentes tipos de lgicas. En la lgica proposicional (tambin llamada lgica de enunciados o clculo proposicional) la representacin del conocimiento se hace mediante aserciones o declaraciones sobre hechos o ideas. En la lgica de predicados (de primer orden) se ampla el concepto de declaracin aadiendo las propiedades y las relaciones entre individuos, junto con cuanticadores (universal y particular). La lgica de predicados incluye a la lgica proposicional como un subsistema y tambin existen lgicas de predicados de orden superior (que incluyen cuanticadores para las funciones) y extensiones como la lgica de predicados con identidad. La lgica de predicados y la lgica proposicional se denominan algunas veces como lgicas clsicas. Para superar algunas de las limitaciones expresivas de las lgicas clsicas, se han propuesto otras formulaciones lgicas. La lgica modal aade (o ampla) al concepto de verdadero o falso para los enunciados, la posibilidad de expresar tambin la necesidad y posibilidad. E incluso en algunos casos se puede aadir la indicacin temporal de los enunciados, dando lugar a la lgica modal temporal. Un planteamiento interesante y con buenos resultados prcticos es la lgica de conjuntos difusos, que habitualmente se abrevia con la denominacin de lgica difusa (en ingls fuzzy set logic, que algunos casos tambin se traduce como lgica de conjuntos borrosos o simplemente lgica borrosa). En la lgica difusa los enunciados utilizan conjuntos cuya denicin no es exacta, sino que permiten un cierto grado pertenencia a sus miembros segn el contexto, lo cual permite representar parte de la imprecisin inherente al lenguaje natural. Otro tipo de lgicas, que intentan suplir el problema del conocimiento asumido en un contexto, son las lgicas no-montonas donde solamente se hacen suposiciones de certeza salvo nuevas conjeturas que las contradigan. Una introduccin a los distintos tipos de lgicas se puede encontrar en [MDGBD95, cap. 5] y de forma resumida (sobre lgica de predicados, modal y difusa) en [FGGBMM98, sec. 3.2].

1.2.2.

Reglas

Las reglas de produccin eran un concepto aparecido en la teora de autmatas y los lenguajes formales que fue aplicado en IA para producir nuevos estados. En la actualidad no se utilizan nicamente con esta intencin, y por tanto, en el contexto de la IA, se habla simplemente de reglas. Podemos considerar que las reglas son a modo de esquemas simplicados y generalizados de expresiones lgicas, que permiten la representacin del conocimiento de una forma simple y muy potente. En las representaciones que utilizan reglas, implcitamente suele haber un mecanismo de inferencia (motor) que transforma las reglas para producir nuevos estados o datos tal como se ver en el Tema 3. La estructura ms comn en las reglas consiste en dos partes: antecedente y consecuente. Esta estructura habitualmente se representa con la sintaxis: SI antecedente ENTONCES consecuente. El antecedente contiene las clusulas que deben cumplirse para que la regla se active o se ejecute. El consecuente est formado por las conclusiones o acciones que son resultado de la ejecucin de la regla. Se pueden repasar los conceptos bsicos de las reglas en [MDGBD95, sec. 6.2]. La recopilacin de muchos tipos de datos de forma organizada, junto con los mecanismos de acceso, modicacin y recuperacin de la informacin, constituye un sistema de base de datos. Aunque las bases de datos no son herramientas especcas de la Inteligencia Articial, s es cierto que se utilizan muy a menudo en las implementaciones de algunos mecanismos de inferencias. Esta utilizacin en IA se puede reconocer en sistemas que contienen bases de armaciones o bases de conocimiento utilizadas en sistemas basados en regla. Aparte

Adquisicin y representacin del conocimiento

tambin son utilizadas en otros sistemas, por ejemplo para almacenar datos sobre casos (para razonamiento basado en casos), etc.

1.3.
1.3.1.

Marcos, guiones y ontologas


Marcos y guiones

Los marcos son esquemas de representacin en los cuales se especican las caractersticas (propiedades, atributos o campos y los valores asociados a ellos) comunes de una clase de objetos o elementos que son las instancias. Se aade en ese esquema la posibilidad de formar una jerarqua entre las clases mediante el mecanismo de herencia de propiedades de los ascendientes. Tambin pueden aparecer diferentes facetas en la denicin de los campos (valor por omisin, tipo multivaluado, restricciones, grado de certeza, interfaz, etc.). En la actualidad los sistemas de marcos tambin incorporan la posibilidad de ejecutar acciones para el acceso y modicacin de los datos almacenados (por valor requerido, modicacin, borrado, asignacin, acceso, etc.). Los sistemas de representacin en marcos son funcionalmente muy parecidos a los lenguajes de programacin orientada a objetos que incorporan las acciones (mtodos) como otras propiedades o campos en el objeto. Los marcos, junto con las reglas y algunos aspectos de las redes semnticas, son una de las bases ms slidas en los sistemas expertos prcticos. Se puede ver una breve descripcin de la representacin en marcos en [MDGBD95, sec. 8.1] y en [FGGBMM98, sec. 6.2.1]. Los guiones surgieron como una ampliacin de los grafos de dependencia conceptual de Schank (ver apartado 1.1.2). Un guin es una estructura de conocimiento que organiza informacin referente a situaciones dinmicas estereotipadas, es decir situaciones donde est jada la secuencia de hechos o acciones. Un guin puede considerarse como un marco en el que cada campo corresponde a un suceso y que estos campos-sucesos forman una secuencia. Se puede encontrar una descripcin bsica de los guiones en [MDGBD95, sec. 8.3.1 y 8.3.2] y en [FGGBMM98, sec. 6.2.2].

1.3.2.

Ontologas

Ms recientemente se estn desarrollando sistemas basados en el conocimiento que incorporan una parte de representacin del conocimiento similar a los marcos, pero con la diferencia de que la parte de inferencia est en otra capa superpuesta, donde se intentan reutilizar los esquemas de inferencia genricos. En la capa inferencial y de control se utilizan las tcnicas de descomposicin de las tareas (de anlisis, modicacin o sntesis) asociadas o relacionadas con los objetos (ver [MDGBD95, sec. 2.4]). Una ontologa, sobre un dominio concreto, es una arquitectura de representacin del conocimiento esttico por un lado e inferencial (sobre ese conocimiento esttico) de tipo genrico, de tal forma que los mecanismos inferenciales son desacoplables del conocimiento esttico (para reutilizarlos en otro dominio). Podemos considerar que una ontologa es una descripcin (formal) de los conceptos y relaciones que pueden existir para un agente o una comunidad de agentes. El objetivo principal de las ontologas es describir el conocimiento de forma que se pueda compartir con otros y reutilizar (al menos parcialmente) en diferentes dominios. Los sistemas de representacin de ontologas que actualmente estn ms extendidos comenzaron con las propuestas iniciales de la metodologa de modelado del conocimiento KADS, que se han desarrollado hacia KADS-II como biblioteca de la metodologa CommonKADS utilizando en gran parte CML (Conceptual Modelling Language). Como resultados de estos trabajos se han desarrollado algunas herramientas (de acceso libre) para descripcin de ontologas a travs de Internet, como O NTOLINGUA http://www.ksl.stanford. edu/software/ontolingua/ y C HIMAERA http://www.ksl.stanford.edu/software/chimaera/. Una herramienta prctica y reciente para representar ontologas, derivada de los trabajos en la Universidad de Stanford, es P ROTG -2000, que se trata de la ltima versin en Java del proyecto P ROTG, http://protege.stanford.edu/. Actualmente tiene varios plugins, para convertir o adaptarse a otras metodologas, incluso uno para OWL (que se comenta en el siguiente prrafo). Actualmente se est desarrollando un lenguaje estndar para representar ontologas en web. Se trata de OWL (Web Ontology Language), cuyas descripciones y especicaciones se encuentran en el grupo de trabajo del WebConsortium, Web Ontology (WebOnt), http://www.w3.org/2001/sw/WebOnt/. Estos trabajos son el resultado de desarrollos anteriores en DAML (DARPA Agent Markup Language), y OIL (Ontology

1.3 Marcos, guiones y ontologas

Inference Layer), que es en gran parte compatible con el lenguaje de RDFS (Resource Description Framework Schema, otro estndar del WebConsortium). Estos proyectos a su vez estn muy relacionados con el proyecto de Semantic Web en el WebConsortium alrededor de RDF (Resource Description Framework). Existe una herramienta de diseo visual para RDF que actualmente tambin soporta OWL, se trata de I SAV IZ, http://www.w3.org/2001/11/IsaViz/.

Tutorial posterior
Resumen de contenidos
ste es el tema en el que se han indicado recordatorios sobre los siguientes mtodos de representacin del conocimiento, habituales en la Inteligencia Articial y la Ingeniera del Conocimiento: 1. rboles como caso particular de los grafos. 2. Redes asociativas de tipos: relacionales, proposicionales, de clasicacin, causales (Bayesianas como caso particular). 3. Lgicas formales: de proposiciones, de predicados, modal, difusa y no-montona. 4. Reglas como esquemas de representacin de proposiciones lgicas. 5. Marcos y guiones para representacin de clases y objetos, o de escenas y sucesos. 6. Ontologas con una representacin de conocimiento esttico desacoplada de los mtodos de inferencia.

Ejercicios y actividades propuestas


Se recomienda al alumno que descargue, instale y pruebe las herramientas para ontologas, P ROTG -2000, OIL ED e I SAV IZ, que se han indicado en el apartado 1.3.2. Es conveniente que siga los ejemplos que vienen en cada una y que intente modicar esos ejemplos para aadir alguna funcionalidad, e incluso que intente describir otra ontologa de algn dominio en el cual el alumno tenga ms conocimientos. Puede resultar conveniente leer antes algunas de las guas sobre edicin y desarrollo de ontologas que se indican en la seccin correspondiente (ver pg. 7) del apartado de extensin de conocimientos de este captulo. As mismo el alumno puede acceder por red (slo requiere registro gratuito) a los servicios en lnea que promociona el Knowledge Systems Laboratory de la Universidad de Stanford en http: //ksl.stanford.edu/software/ontolingua/, especialmente a las herramientas C HIMAERA y O NTOLINGUA.

Extensin de conocimientos
Para obtener otros puntos de vista generales en cuanto a la representacin del conocimiento (y del razonamiento) se puede ver el libro de Nilsson [Nil01, caps. 13 al 20], en especial ms dedicado a las representaciones de la lgica y reglas. Manipulacin, edicin y visualizacin de grafos Si se realizan programas que manejen grafos en lenguaje C++, es muy conveniente utilizar la biblioteca GTL (Graph Template Library ), en http://www.infosun.fmi.uni-passau.de/GTL/, ya que est basada en la conocida STL (Standard Template Library ). Esta biblioteca proporciona (plantillas de) algoritmos para bsquedas, recorridos, ujos, mnimos rboles, etc que son comunes en la manipulacin de las representaciones en grafos. Incluso hay un programa de edicin y visualizacin de grafos realizado con esta biblioteca, se trata de G RAPHLET http://www.infosun. fmi.uni-passau.de/Graphlet/. El cdigo fuente y binarios precompilados estn disponibles de forma gratuita para usos no-comerciales.

Adquisicin y representacin del conocimiento

Tambin existe un conjunto de bibliotecas y herramientas para manipular estructuras de objetos matemticos discretos, entre los que se incluyen la manipulacin de grafos y su visualizacin, llamado L INK (parte de los proyectos D IMACS), en http://dimacs.rutgers.edu/~berryj/LINK. html. En la edicin y visualizacin de grafos se puede utilizar la herramienta G RAPHTOOL http: //projects.skewed.de/graph-tool/ que es de libre distribucin. Tambin se pueden crear editores propios utilizando las bibliotecas de D IAG EN http://www.unibw.de/inf2/DiaGen/ (o utilizar alguno de los que se muestran en su pgina web). La visualizacin de grafos, especialmente con distribucin automtica en el plano, es un tema muy amplio. En la pgina web http://www.graphdrawing.org/literature/ se puede encontrar una detallada relacin de referencias bibliogrcas sobre el tema. Tambin hay una buena relacin de recursos en Internet sobre visualizacin de grafos en la pgina http://www.ics. uci.edu/~eppstein/gina/gdraw.html. Para la visualizacin y navegacin en informacin representada como grafos o redes la herramienta TOUCH G RAPH (en Java), proyecto en http:// touchgraph.sourceforge.net/, proporciona lo necesario para desarrollar programas adecuados. Redes asociativas Sobre los temas particulares de redes Bayesianas (y tambin sobre lgica difusa y factores de certeza) es muy interesante el libro de texto (apuntes) [De98] y el libro [CGH97] (disponible en Internet). Tambin hay muchas referencias a recursos en Internet (software incluido) sobre redes Bayesianas y diagramas de inuencia en la pgina http://www.ia.uned.es/~fjdiez/bayes/. Lgica Por supuesto, en la asignatura previa (en cuarto curso de esta titulacin) de Lgica Computacional se estudian ms ampliamente la lgica proposicional, la lgica de predicados, la programacin lgica y la lgica modal. Se puede consultar el material correspondiente en [FMD03]. Los sistemas utilizados habitualmente para implementar sistemas que utilicen las lgicas clsicas son los lenguajes Prolog y LISP (de los cuales es fcil encontrar compiladores y entornos). El primero debido a que incorpora de forma implcita la resolucin de proposiciones lgicas y el segundo debido a su versatilidad y facilidad en el manejo de proposiciones. Sobre la lgica de conjuntos difusos se puede encontrar algunas referencias en la lista de preguntas frecuentes (FAQ) del grupo de news comp.ai.fuzzy en http://www.cs.cmu.edu/Groups/ AI/html/faqs/ai/fuzzy/part1/faq.html. Hay un sistema de desarrollo (escrito en C con interfaz grca en Java) para sistemas de lgica difusa, FOOL (Fuzzy Organizer OLdenburg), en http://sourceforge.net/projects/fool. Entornos de reglas y marcos Un entorno muy conocido de representacin de conocimiento es MIKE (Micro Interpreter for Knowledge Engineering) http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/ expert/systems/mike/0.html. Este entorno (que requiere Prolog tipo Edinburgh) incluye, entre otras caractersticas, encadenamiento de reglas hacia delante y atrs, ms un lenguaje de representacin de marcos con herencia. En parte, uno de los sucesores de los estudios de MIKE es HANK (Cognitive Modelling Environment), tambin desarrollado en la Open University : http://kmi.open.ac.uk/projects/ hank/. Algunos de los resultados de MIKE que han dado lugar a otros desarrollos posteriores estn aglutinados en el proyecto ENCODE (en la Universidad Tcnica de Koice). En la siguiente pgina s se pueden encontrar descripciones y referencias sobre los elementos OUSEL, OCML y CSE en el ENCODE W ORKBENCH: http://www.tuke.sk/kkui/projects/encode/encwb.html. Se pueden ver tambin algunas de las herramientas indicadas en el apartado de extensin de conocimientos del tema 3 (pg. 20) sobre inferencia con reglas y casos.

1.3 Marcos, guiones y ontologas

Ontologas Para una descripcin ms detallada de KADS, CML, etc., ver por ejemplo [WSB92], aparte de las pginas web correspondientes (indicadas en el apartado 1.3.2), ms http://www.commonkads. uva.nl/. Una revisin e introduccin sobre el lenguaje OWL se puede encontrar en http://www.w3. org/TR/owl-features/ y una descripcin ms formal y detallada en la gua de referencia correspondiente http://www.w3.org/TR/owl-ref/ (ambas en ingls). Sobre DAML se puede consultar la pgina del proyecto http://www.daml.org/. Sobre cmo crear y editar ontologas, especialmente usando P ROTG -2000, hay una gua (en ingles) en la pgina http://protege.stanford.edu/publications/ontology_development/ ontology101.shtml. Hay extensa y detallada informacin sobre RDF en la pgina correspondiente del WebConsortium http://www.w3.org/RDF/. Tambin hay herramientas para el modelado del conocimiento mediante mapas conceptuales, como CM AP TOOLS (knowledge modelling kit for Concept Maps) http://cmap.ihmc.us/.

Adquisicin y representacin del conocimiento

Tema 2

Tcnicas de bsqueda en espacio de posibles soluciones


Tutorial previo
Introduccin
Las tcnicas de bsqueda son una de las bases en muchos de los mtodos de solucin de problemas de la Inteligencia Articial. Los mtodos genricos de bsqueda se pueden aplicar desde el momento en que podemos plantear un problema en trminos de estados hacia la solucin, o de potenciales soluciones, y proporcionar un mecanismo para generar nuevos estados, bien a partir de los actuales (o conocidos), o bien directamente nuevos estados.

Relacin con otros temas


En este tema se presentan los mtodos de bsqueda en espacio de soluciones. El espacio de soluciones se suele representar en forma de grafo, con lo cual se deben aplicar los conocimientos sobre grafos del tema anterior en los apartados 1.1.2 y 1.1.1. La mayor parte de los mtodos de bsqueda estn descritos como algoritmos en los cuales se especican una serie de pasos utilizando operadores sobre listas y conjuntos de nodos.

Objetivos del tema


Ya que la bsqueda es uno de los mecanismos ms productivos de las tcnicas bsicas de la IA, es importante conocer los diferentes tipos de algoritmos de bsqueda y tambin relacionarlos todos entre s para tener una idea general de cmo son estos algoritmos (todos encajan en esquemas similares), por tanto el objetivo es obtener esa visin global y entender cmo se puede aplicar a diferentes problemas.

Gua de estudio y esquema


Es conveniente realizar una lectura inicial del tema para comprobar cules son los aspectos que se deben conocer en el mismo. Posteriormente, se debe acudir a repasar los conceptos y mtodos, ya estudiados previamente y que sea necesario recordar, a travs de las referencias dadas en cada apartado o en la bibliografa que se us en las asignaturas previas en las cuales se hayan estudiado. El tema tiene tres partes: Exploracin exhaustiva (bsqueda bsica) Bsqueda basada en conocimiento heurstico Bsqueda hbrida: computacin evolutiva

10

Tcnicas de bsqueda en espacio de posibles soluciones

2.1.

Exploracin exhaustiva (bsqueda bsica)

La gran mayora de los problemas planteados en el campo de la IA pueden formularse como una tarea de bsqueda entre las posibles soluciones. Las caractersticas esenciales para aplicar algoritmos de bsqueda son la existencia de un mtodo para generar otro estado desde uno cualquiera dado y la posibilidad de detectar las metas u objetivos. Los pasos para ir de un estado a otro en la solucin se representan por los arcos de un grafo que tiene los estados en los nodos. Si adems vamos a aplicar tcnicas directas, deben conocerse los estados iniciales de partida. Si la solucin debe ser exacta u ptima, debe existir al menos un estado meta o estado solucin. Casi todos los algoritmos utilizan grafos para el control de la bsqueda, aparte de que el problema en s mismo est planteado (o representado) como un grafo. Este ltimo caso es habitual cuando el problema se ha reducido a un recorrido en un grafo (ejemplo salida de un laberinto, o hallar el camino ms corto en un mapa, etc.). Cuando la representacin del problema es directamente un grafo conocido a priori en extenso, ese grafo se usar en el algoritmo. En el resto de los casos, hay que ir construyendo el grafo incrementalmente al explorar nodos, sobre todo si el grafo es muy grande y no se hace bsqueda exhaustiva, o bien si no es posible conocerlo de antemano (slo por interaccin con el sistema). Los algoritmos ms inmediatos para realizar la bsqueda son aquellos basados en la exploracin exhaustiva de todos los nodos del grafo de estados para encontrar el mejor camino desde los estados iniciales a los estados meta. Dentro de este tipo de algoritmos hay dos tipos de esquema de funcionamiento, el esquema de produccin en el cual se realiza una bsqueda explcita en el espacio de estados y el esquema de reduccin donde el grafo (en este caso suele ser rbol) representa estados de resolucin dividiendo el problema en otros menores.

2.1.1.

Esquema de produccin (bsqueda en espacio de estados)

Cuando el problema se representa por un grafo con forma de rbol (es decir, solo hay un camino de llegada a cada nodo), se pueden aplicar mtodos de bsqueda, especialmente diseados para rboles, que se corresponden con una ordenacin de los nodos. Estos mtodos pueden ser: exploracin en amplitud, exploracin en profundidad, exploracin con retroceso, y otros derivados de ellos, como profundidad progresiva, bidireccional, etc. La diferencia en ellos est en que la ordenacin se realiza primer por los nodos descendientes directos y despus se aplica a cada uno de ellos, o bien al revs, o mezclando ambas formas. Las descripciones detalladas de estos mtodos de bsqueda se pueden encontrar en [MDGBD95, sec. 3.4], y de forma ms resumida en [FGGBMM98, sec. 1.2]. Tambin se pueden disear algoritmos generales para exploracin de grafos (no necesariamente rboles). Estos algoritmos se basan en tener una forma de decidir el orden de comprobacin de los nodos conectados a uno dado, o el orden entre un conjunto de nodos. Esta forma de explorar grafos es la misma que se puede aplicar con los mtodos heursticos (que se comentan en el apartado 2.2), salvo que cuando no tenemos informacin heurstica, se elige el mejor hasta el momento basndose en una medida de coste conocido (por omisin es la longitud del camino). La estructura de los algoritmos generales de bsqueda en grafos se explica en [MDGBD95, sec. 3.6] y tambin en [FGGBMM98, sec. 1.2].

2.1.2.

Esquema de reduccin (divisin en subproblemas)

En lugar de resolver el problema pasando por diferentes estados, se puede plantear la posibilidad de que se divida el problema en otros ms sencillos. Este esquema de resolucin se denomina reduccin del problema. En este caso, se trata de analizar en cada caso el problema a resolver y generar a partir de ste otros subproblemas (ms sencillos) y volver a aplicar en cada uno la misma tcnica hasta que se alcanza un subproblema que tiene (o es en s mismo) una solucin trivial. Las condiciones para que este tipo de bsqueda sea aplicable son: poder generar subproblemas independientes a partir de un problema dado, por tanto existe el operador adecuado la existencia de un mecanismo que permita expresar la solucin como una composicin de las soluciones de los subproblemas generados la deteccin de soluciones inmediatas o problemas con solucin trivial

2.2 Bsqueda basada en conocimiento heurstico

11

Este planteamiento se representa habitualmente con rboles Y/O, que son rboles (ver apartado 1.1.1 sobre representacin de conocimiento) en los cuales los nodos son los subproblemas (o submetas a alcanzar) y la conexin entre nodos puede ser de tipo O, cuando son varias alternativas, o de tipo Y cuando deben resolverse todos los subproblemas. Esto est ms detallado en [MDGBD95, sec. 3.5]. En la prctica, este tipo de planteamiento se puede resolver tambin por los mtodos algortmicos planteados en la bsqueda de espacio de estados (apartado 2.1.1), e incluso con los mtodos de la bsqueda heurstica (apartado 2.2), sin ms que tener en cuenta que los operadores para generar nuevos nodos son de distinto tipo y las restricciones de conexiones alternativas o conjuntas.

2.2.

Bsqueda basada en conocimiento heurstico

En los mtodos de exploracin exhaustiva se recorre el grafo (o rbol) que representan los estados de una forma sistemtica, en la que el orden de recorrido est preestablecido por la conectividad de los nodos. En muchos casos ocurre que el orden de conectividad de los estados no se corresponde con el orden ms eciente para encontrar la solucin, puesto que es independiente del problema. En algunos problemas, no slo es importante encontrar la mejor solucin, sino que a veces es ms interesante encontrar alguna buena solucin en menos tiempo (o utilizando menos recursos). Para reducir el tiempo y recursos utilizados en las bsquedas donde aparece el problema de la explosin combinatoria, se debe aadir el conocimiento del dominio. De esta forma se pueden evitar las comprobaciones de caminos que se sabe no van a dar una solucin, o simplemente se exploran en primer lugar las alternativas que ms posibilidades tienen de llegar a una solucin (ptima denitiva simplemente vlida). En muchas ocasiones, ese conocimiento proviene de mtodos de prueba y error previos, o simplemente de tanteos e intentos durante el curso de la misma bsqueda. En otros casos, ese conocimiento se extrae de reglas empricas formuladas en base al conocimiento de un experto o a partir de soluciones encontradas en dominios similares. En la prctica la mayor parte de las bsquedas heursticas se hacen con algoritmos muy similares a los comentados en el apartado 2.1 sobre exploracin exhaustiva, salvo que a la hora de elegir el orden de exploracin de los nodos se utiliza ms informacin del dominio para comenzar primero por los ms prometedores. Incluso son modicaciones de esos algoritmos para evitar explorar ciertos nodos que se sabe que no pueden conducir a ninguna solucin. Esta informacin adicional se suele aglutinar o condensar en las denominadas funciones de evaluacin heurstica que nos devuelven indicadores (nmeros) con valoraciones exactas o estimaciones aproximadas sobre la ventaja e idoneidad de cada nodo respecto a la exploracin de caminos hacia la solucin. Los valores devueltos por cada funcin de evaluacin heurstica suelen ser de tipo numrico relacionadas con una distancia o coste para alcanzar la solucin, o con la calidad de la solucin hallada hasta el momento. Una eleccin adecuada de estas funciones heursticas es esencial para la eciencia de la bsqueda heurstica.

2.2.1.

Estrategia irrevocable: mtodo del gradiente

Este es un mtodo que solamente se puede aplicar cuando se sabe que en el problema la funcin de evaluacin heurstica cumple la condicin de ordenacin estrictamente unvoca (no es fcil encontrarla), es decir que sea mxima en la meta y que para cada nodo exista un sucesor con un valor mayor. En esas condiciones, al aplicar este algoritmo se trata, simplemente, de ir eligiendo solamente el camino de exploracin para avanzar siempre hacia la solucin (subir por el mximo para llegar a la cima). Por este motivo se suele denominar mtodo del gradiente o bsqueda en escalada. El ahorro puede ser considerable puesto que en cada nuevo nivel de nodos descendientes solamente se elige uno de ellos para continuar la bsqueda y nunca se vuelve hacia atrs. Este mtodo est descrito en [MDGBD95, sec. 4.2] y [FGGBMM98, sec. 2.2.2].

2.2.2.

Exploracin de alternativas

Cuando no disponemos de una funcin de evaluacin heurstica estricta, sino que se trata de algo aproximado o parcial. En este caso la informacin disponible puede ayudar a elegir primero los caminos ms prometedores. Como ya hemos mencionado antes, casi todos estos algoritmos son los mismos de la exploracin exhaustiva salvo por la ordenacin a la hora de expandir los nodos de bsqueda. El algoritmo ms sencillo e inmediato de este tipo es el de primero el mejor que, como su nombre indica, consiste en ordenar los nodos en cada expansin y elegir primero el que mayor valor tenga en la funcin de

12

Tcnicas de bsqueda en espacio de posibles soluciones

evaluacin heurstica, sin tener en cuenta el coste hasta ese nodo. Se utiliza el algoritmo de bsqueda general en grafos comentado en el apartado 2.1.1. Si durante el proceso de expansin se limita el nmero de nodos potenciales a explorar, estamos ante una variante del mtodo anterior conocida como bsqueda en haz (beam search). La reduccin de nodos se puede realizar en funcin de criterios sobre la cantidad mxima de los nodos con mejor valor, o bien sobre el valor umbral mnimo de la funcin heurstica de los nodos a expandir. El algoritmo A* es una variante de primero el mejor en la cual se aade a la funcin de evaluacin heurstica de cada nodo el coste real (conocido) del mejor camino encontrado para llegar hasta ese nodo desde el origen. Adems este algoritmo se puede generalizar para la exploracin de los rboles Y/O (mencionados en el apartado 2.1.2) que se utilizan para representar problemas en los que se pueden encontrar soluciones reduciendo el problema a otros subproblemas ms sencillos. Este tipo de exploracin seleccionando las alternativas est ms ampliamente descrito en [MDGBD95, sec. 4.3] y [FGGBMM98, sec. 2.2.3].

2.2.3.

Bsqueda con adversarios

Cuando por las condiciones del problema se dan pasos alternados de benecio o perjuicio hacia la solucin buscada, estamos ante un tipo de problema que se puede modelar como un juego. En especial son interesantes los juegos por turnos donde todos los bandos conocen toda la informacin disponible. En este caso se realiza una seleccin de camino y la meta o solucin se puede decidir de manera precisa segn las reglas. Hay juegos muy sencillos donde el rbol (o grafo) de posibilidades es pequeo y resulta factible realizar una bsqueda exhaustiva, pero cuando las posibilidades aumentan, la explosin combinatoria puede hacer este tratamiento inabordable. En estos casos se hace necesario limitar la bsqueda en cuanto a la seleccin de nodos o del nmero de niveles de profundidad a explorar, realizar un movimiento y esperar la respuesta del contrincante para volver a reevaluar la situacin de la misma forma. La mayor parte de las estrategias de bsqueda con adversarios (con dos jugadores) se basa en el algoritmo MiniMax. Este algoritmo consiste en ir etiquetando cada nodo explorado hasta una profundidad limitada, segn el valor de una funcin de evaluacin heurstica que reeja las posibilidades estimadas de ganar en un estado determinado del problema (juego). Este valor obtenido en los nodos nales se va propagando hacia los nodos padres calculando el mximo o el mnimo (segn qu bando mueve, lo que equivale a rboles Y/O) de los valores de los descendientes. Si en la exploracin se encuentra un nodo nal (pierde, gana o empata), su valor decide el valor de sus nodos ascendientes (por los que se llega a esa solucin) dependiendo del tipo de nodo (Min Max). La variante ms ampliamente utilizada del algoritmo MiniMax incluye la poda como un mecanismo de seleccin de caminos. Esta seleccin evita explorar los descendientes de un nodo en el momento que las alternativas (Min Max) nos permiten decidir que es imposible encontrar una solucin mejor por ese camino. El nombre proviene de la nomenclatura habitual, en la que es el mnimo valor de un nodo MIN para ser explorado, y es el mximo valor de un nodo MAX para ser explorado. Los nodos que no pueden cumplir el valor correspondiente son simplemente descartados de la bsqueda. Esta variante permite reducir mucho la extensin del rbol de bsqueda, y por tanto utilizar los recursos disponibles para descender a mayor profundidad en los caminos prometedores. Este tipo de bsqueda con adversarios y en particular el mtodo MiniMax con poda estn detallados en [MDGBD95, sec. 4.4] y [FGGBMM98, sec. 2.2.4].

2.3.
2.3.1.

Bsqueda hbrida: computacin evolutiva


Introduccin

Cuando se utiliza una mezcla de exploracin exhaustiva (y en parte estocstica), pero limitada por cierto conocimiento heurstico, nos encontramos con los algoritmos de tipo evolutivo. Estos mtodos de bsqueda, inspirados en los procesos naturales de evolucin, se encuadran en lo que genricamente se denomina computacin evolutiva, en la cual se engloban los algoritmos genticos, la programacin evolutiva, la programacin gentica, las estrategias evolutivas, etc.

2.3 Bsqueda hbrida: computacin evolutiva

13

Listado 2.1: Pseudo-cdigo para la estructura general de los algoritmos evolutivos.


// Marcar tiempo inicial t := 0; // Inicializar poblacin (aleatoria) de individuos initpopulation P(t); // Evaluar adecuacin de los individuos en la poblacin inicial evaluate P(t); // Comprobar criterios de final (tiempo, adecuacin, etc.) while not done { // Seleccionar sub-poblacin para produccin de descendencia Pnew(t) := selectparents P(t); // Recombinar "genes" de los padres seleccionados recombine Pnew(t); // Perturbar aleatoriamente la poblacin mezclada mutate Pnew(t); // Evaluar su nueva adecuacin evaluate Pnew(t); // Seleccionar los supervivientes segn adecuacin efectiva P(t+1) := survive P(t),Pnew(t); // Incrementar el contador de tiempo t := t + 1; }

Los mtodos de solucin de tipo evolutivo se basan en la bsqueda de soluciones mediante la comprobacin y valoracin de las nuevas posibles soluciones, que se van construyendo a partir de la recombinacin de ciertas caractersticas de las mejores soluciones encontradas en pasos previos. La principal diferencia con los mtodos de bsqueda comentados anteriormente est en que para la computacin evolutiva se requieren potenciales soluciones completas, y no los pasos en un camino hacia la solucin denitiva como en la exploracin exhaustiva o la bsqueda heurstica. De forma que en este caso, tambin se realiza una exploracin de todas las posibilidades, aunque dirigida por una cierta heurstica sobre la calidad de las soluciones analizadas y las caractersticas de cada solucin que intervienen en esa calidad. La heurstica que dirige la eleccin de nuevas soluciones potenciales se basa en procesos de seleccin, mutacin y reproduccin, controlados por el rendimiento de estructuras individuales tal como lo dena un medio o entorno.

2.3.2.

Estructura

Los algoritmos evolutivos en general mantienen una poblacin de estructuras (representaciones de soluciones posibles) que evolucionan segn unas reglas de seleccin y operadores de bsqueda (operadores genticos), como recombinacin y mutacin. Cada individuo de esa poblacin recibe una medida de su adecuacin en un entorno (representacin del problema). La reproduccin se centra en seleccionar los individuos de mayor grado de adecuacin (simulando la supervivencia por seleccin en una competencia por los recursos del entorno). Mediante la recombinacin (cruzado gentico) y la mutacin se modican esos individuos, lo cual proporciona la heurstica general de la exploracin. La clave en estos mtodos es la adecuada representacin de las caractersticas de las soluciones para que la bsqueda en el espacio de posibles soluciones se pueda realizar con individuos prximos entre s respecto a sus ventajas o adecuacin como solucin y a la correcta denicin de la funcin de medida de la adecuacin. Con estas caractersticas heursticas se pueden obtener mejores resultados que con una simple bsqueda estocstica (aleatoria). La estructura general de los algoritmos evolutivos est representada en forma de pseudo-cdigo en el listado 2.1, donde se puede observar que, despus de la inicializacin, se repite la secuencia de operadores de seleccin, recombinacin, mutacin y supervivencia basada en la adecuacin, hasta alcanzar algn criterio de nalizacin (mximo tiempo o ciclos, grado de adecuacin mxima alcanzado, etc.).

14

Tcnicas de bsqueda en espacio de posibles soluciones

2.3.3.

Tipos

Los algoritmos genticos se distinguen por utilizar una codicacin de parmetros en una cadena de longitud ja, mientras que la programacin gentica utiliza la codicacin de reglas de produccin o programas (usualmente en LISP) en forma de rboles sintcticos de longitud variable. La programacin evolutiva es un paradigma similar a los algoritmos genticos pero con una representacin de las soluciones dependiente del problema (conocimiento sobre el problema dentro del algoritmo) y poniendo ms nfasis en la parte de perturbaciones estocsticas (mutaciones) proporcionales a una distribucin de media cero, sin recombinacin cruzada, para generar la descendencia, y aadiendo tambin una parte estocstica en la seleccin de los supervivientes (competiciones aleatorias entre individuos). Las estrategias evolutivas son similares a la programacin evolutiva, salvo que tambin se utiliza recombinacin cruzada, pero aadiendo una parte de aleatoriedad en la seleccin de los candidatos a los cruzamientos y dando ms importancia a la optimizacin paramtrica. Existe una biblioteca de programacin en C++ (en desarrollo avanzado) para computacin evolutiva llamada EO. Est disponible como software de libre distribucin en http://eodev.sourceforge.net/. Esta biblioteca est compuesta de clases denidas para casi todos los elementos necesarios en computacin evolutiva. En las referencias del apartado extensin de conocimientos se pueden encontrar otras bibliotecas y programas de aplicacin. En esta asignatura no se har ms nfasis sobre estos mtodos, el alumno interesado en el tema puede encontrar ms informacin relativa a la Computacin Evolutiva en el apartado de extensin de conocimientos de este tema.

Tutorial posterior
Resumen de contenidos
En este tema se han recordado los mtodos ms importantes de bsqueda en el espacio de soluciones, utilizando algoritmos similares en su planteamiento y en su representacin: 1. Exploracin exhaustiva bsqueda bsica sin conocimiento especco del dominio, tanto en representaciones con esquemas de produccin como con esquemas de reduccin (divisin en subproblemas). 2. Bsqueda basada en conocimiento heurstico. 3. Bsqueda con heurstica del mtodo del gradiente. 4. Bsqueda por exploracin de alternativas: mtodo de primero el mejor, algoritmo A*, variantes para rboles Y/O. 5. Bsqueda con adversarios: mtodo MiniMax con variante por poda . 6. Bsqueda hbrida: computacin evolutiva en la que se mezcla una parte de seleccin guiada por conocimiento y otra de exhaustividad por azar. 7. Estructura general de los algoritmos evolutivos. 8. Tipos de computacin evolutiva: algoritmos genticos, programacin evolutiva y estrategias evolutivas.

Ejercicios y actividades propuestas


Se recomienda al alumno que identique los componentes de los diferentes algoritmos e intente describir cmo se realiza la equivalencia de los algoritmos de bsqueda exhaustiva en rboles en el esquema de algoritmos generales de bsqueda en grafos. De la misma forma, es conveniente identicar cules son los esquemas comunes a los mtodos heursticos (y con la bsqueda exhaustiva) que permitiran implementar algoritmos genricos simplemente instanciando las funciones de generacin de nodos, y de ordenacin o prioridad de nodos en una cola, etc. Esto le permitir desarrollar o valorar posibles implementaciones tiles para resolver ms cantidad de problemas de bsqueda.

2.3 Bsqueda hbrida: computacin evolutiva

15

Extensin de conocimientos
Este tema tambin se puede estudiar en el libro de Nilsson [Nil01, caps. 4 y 7 al 12] sobre sistemas evolutivos y sobre la bsqueda en general. Hay un ejemplo muy interesante de aplicacin genrica de los algoritmos de bsqueda. Se trata del programa G TKBOARD (la pgina del proyecto es: http://gtkboard.sourceforge.net/), que implementa una interfaz genrica para juegos de tablero por turnos. En el programa se ha implementado un algoritmo de bsqueda alfa-beta y tablas de transposicin que se puede usar para cualquier juego (de dos jugadores). Es un proyecto de software libre y todos los cheros fuentes estn disponibles. De hecho, puede ser interesante echarles un vistazo en el CVS del proyecto: http://gtkboard.cvs.sourceforge.net/gtkboard. Actualmente el desarrollo del programa est parado, pero ya est funcional (se puede usar) e incorpora de momento 31 juegos (ajedrez y alguna variante, othello, puzles, alineaciones, mastermind, etc.). Para aadir otro juego solo es necesario programar las funciones de denicin de tablero, piezas e interfaz de movimientos (saber qu movimiento solicita el jugador). Si adems se quiere que el nuevo juego use el motor de bsqueda del programa hay que aadir dos funciones, una que devuelve la lista de posibles movimientos para una posicin y otra que valora una posicin dada (puntuacin heurstica). Hay una explicacin ms detallada en el apartado Hacking, Writing a new game de la pgina web de G TKBOARD. El programa G TKBOARD es muy especco para entornos tipo GNU-L INUX /U NIX con las libreras GTK (de hecho se puede encontrar ya incluido en varias distribuciones de L INUX). No est pensado para entornos Microsoft-Windows (aunque quiz se pueda usar bajo C YGWIN http: //cygwin.com/). De todas formas, para entornos Microsoft-Windows1 existe un programa comercial similar (de hecho es en el que se ha inspirado G TKBOARD) llamado Z ILLIONS OF G A MES , en http://www.zillions-of-games.com/, aunque el fuente no est disponible, hay una versin de demostracin gratuita. Este ltimo programa proporciona un lenguaje de denicin interpretado, para escribir nuevos juegos, llamado ZRF2 (ver http://web.archive.org/web/ 20020213074824/http://cruise.de/jens.markmann/zrf.html). Otro de los objetivos (a largo plazo) en G TKBOARD es tambin hacer un interprete (o un transformador a C) de ese lenguaje ZRF, ya que existe una extensa base de juegos escritos en l debido a contribuciones de muchas personas. Aparte de los algoritmos y fuentes correspondientes a bsqueda asociados al libro [RN96] (ver http://aima.cs.berkeley.edu/code.html), ya comentado como bibliografa general, tambin en la pgina web del libro [TB97] hay un enlace, http://www.neiu.edu/~kwtracy/ooai-book/ download.html, para descargar una biblioteca de algoritmos generales de bsqueda para lenguaje C++, que incluye bsqueda en profundidad, amplitud, bidireccional, en rboles Y/O, etc. Esta es una versin ms reciente de la antigua biblioteca AI C++ S EARCH que se encuentra en http: //www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/search/aisearch/. En cuanto a computacin evolutiva, es muy recomendable el detallado informe en castellano de Anselmo Prez Serrada [PS96] (de unas 180 pg., disponible en dominio pblico por Internet), que contiene amplias descripciones y referencias bibliogrcas, as como referencias a herramientas software de desarrollo y aplicacin. Tambin puede ser muy interesante la FAQ del grupo de news comp.ai.genetic [HB01], que es el documento base en el sitio de recopilacin de recursos sobre Computacin Evolutiva, ENCORE http://zeus.etsimo.uniovi.es/pub/EC/. Sobre programacin gentica en particular, hay un sitio que recopila informacin sobre el tema en http://genetic-programming.org/. Existen otros mtodos algortmicos de la resolucin de problemas de bsqueda de caminos en una solucin que no se han tratado en este captulo. Por ejemplo, cuando un problema se plantea conociendo el origen y destino, pero lo que se busca es el camino ptimo en una secuencia de selecciones en etapas, tambin pueden ser interesantes otras tcnicas como la programacin dinmica (dynamic programming) que es una especie de optimizacin recursiva hacia atrs (de ah la necesidad de conocer el destino u objetivo deseado). En este caso, el apelativo programacin es una
1 Tambin 2 La

funciona en otros sistemas usando W INE http://www.winehq.org/. documentacin sobre ZRF se puede encontrar en la ayuda interna del programa Zillions of Games.

16

Tcnicas de bsqueda en espacio de posibles soluciones

forma alternativa de referirse a la optimizacin y el adjetivo dinmica hace referencia al avance en el tiempo. En otro contexto, se podra referir a lenguajes dinmicos de programacin de ordenadores (como L ISP o DYLAN con creacin de tipos y clases en tiempo de ejecucin, no de compilacin), pero no es este caso. Este tema se trata con detalle dentro de la asignatura optativa Optimizacin Discreta.

Tema 3

Sistemas de razonamiento o inferencia basados en reglas y en casos


Tutorial previo
Introduccin
Los sistemas de inferencia basados en reglas son los ms habituales en los sistemas expertos. Adems, habitualmente, suelen estar mezclados con otros sistemas de inferencia basados en los tipos de representacin del conocimiento indicados en el tema 1. La estructura de estos sistemas suele estar tambin muy relacionada con los sistemas basados en casos (tambin utilizan bases de datos o conocimiento y generan reglas, etc.).

Relacin con otros temas


Como ya hemos mencionado antes este tema est muy relacionado con la representacin de datos mediante la lgica y las reglas que se coment en el apartado 1.2. Tambin veremos que hay gran relacin con las representaciones de marcos y guiones del apartado 1.3.

Objetivos del tema


Recordar, en forma de visin general, la gran relacin que hay entre los diferentes sistemas de inferencia y razonamiento y su dependencia del sistema de representacin del conocimiento, para descubrir en las aplicaciones prcticas las caractersticas de cada mtodo de resolucin.

Gua de estudio y esquema


Es conveniente realizar una lectura inicial del tema para comprobar cules son los aspectos que se deben conocer en el mismo. Posteriormente, se debe acudir a repasar los conceptos y mtodos, ya estudiados previamente y que sea necesario recordar, a travs de las referencias dadas en cada apartado o en la bibliografa que se us en las asignaturas previas en las cuales se hayan estudiado. El tema tiene dos partes: Inferencia basada en reglas Razonamiento basado en casos

3.1.

Inferencia basada en reglas

Cuando tenemos representado el conocimiento en forma de reglas, necesitamos algn mecanismo que nos permita obtener alguna informacin o reaccin del sistema en funcin de la situacin que debamos resolver. La 17

18

Sistemas de razonamiento o inferencia basados en reglas y en casos

estructura habitual de los sistemas de inferencia basados en reglas es un ncleo de evaluacin, llamado motor de inferencia, que recibe y vuelva informacin en varios sistemas de almacenamiento de informacin (bases de datos). Los datos que maneja el motor de inferencia son de dos tipos reglas y armaciones (hechos). Las reglas se almacenan en la base de conocimientos y las armaciones en una base de armaciones. Adicionalmente el sistema de inferencia debe tener una forma de recibir los problemas y enviar sus soluciones, que es a travs de la interfaz de usuario. La comunicacin con el usuario suele ser de en forma de preguntas/respuestas esquemticas. Los sistemas de inferencia basada en reglas se ven en ms detalle en [MDGBD95, secs. 6.1 a 6.5] y [FGGBMM98, secs. 4.2.1 a 4.2.4]

3.1.1.

Tipos de inferencia

La forma ms inmediata de utilizar el conocimiento representado mediante reglas es seguir de forma directa los efectos de las mismas. As nos encontramos con el tipo de inferencia por encadenamiento hacia adelante (tambin llamado progresivo) o basado en datos. Este mtodo es un tipo de proceso deductivo ya que se trata de hallar los efectos a partir de las causas. De forma intuitiva el algoritmo consiste en comprobar todos los antecedentes de las reglas para ver cuales se cumplen y activar su consecuente (accin) con el resultado de nuevos hechos o condiciones. Estas nuevas condiciones nos obligan a volver a comprobar otra vez qu reglas se cumplen y as repetidamente hasta que en una iteracin no haya reglas que se cumplan. El algoritmo esbozado en el prrafo anterior es bastante burdo y poco eciente. Lo ms habitual es ahorrar las repeticiones de comprobaciones sobre reglas cuyos antecedentes no han cambiado, haciendo as una forma de encadenamiento incremental hacia adelante. El algoritmo rete, que es una mejora del tipo encadenamiento incremental hacia adelante, se basa en comprobar solamente las reglas que tienen condiciones que pueden haber cambiado en la ltima accin realizada. Se va construyendo una red de dependencias que se va modicando segn se cumplen condiciones que disparan otras reglas o segn se aaden condiciones candidatas a nuevas activaciones de reglas. En la prctica la mayor parte de los sistemas de reglas con encadenamiento hacia adelante utilizan el algoritmo rete para su evaluacin de las reglas. El algoritmo rete est explicado con detalle en [FGGBMM98, sec. 4.2.4]. Otra forma de obtener los resultados deseados es mediante el encadenamiento hacia atrs (tambin llamado regresivo) o basado en objetivos. Este mtodo es un tipo de proceso abductivo, en el cual se trata de hallar las causas que pueden dar lugar a los efectos observados. De esta forma se salva el problema de la obtencin de hechos irrelevantes que ocurre en el encadenamiento hacia adelante, al estar dirigido hacia los objetivos deseados. Los algoritmos utilizados para hacer el encadenamiento hacia atrs son habitualmente del tipo de bsqueda en profundidad con retroceso (comentados en el apartado 2.1.1). Un ejemplo tpico de sistema con encadenamiento hacia atrs implcito es el lenguaje de programacin Prolog.

3.1.2.

Reglas con incertidumbre

El mundo real no siempre es fcil de representar con reglas exactas que provienen de la lgica de proposiciones (o incluso con reglas derivadas de la lgica de predicados). En cambio, los expertos suelen tener un conocimiento aproximado sobre ciertas condiciones que suelen dar como resultado ciertas conclusiones. Las fuentes de la incertidumbre pueden ser tambin el resultado de informacin incompleta, imprecisa o parcialmente errnea (aunque la regla sea exacta y correcta). En estos casos se suelen incluir mecanismos que permiten seguir utilizando en su mayor parte los mecanismos de inferencia pero aadiendo variantes, como son los factores de certeza y las reglas difusas. Estos mecanismos se explican en [MDGBD95, sec. 6.6] y [FGGBMM98, sec. 4.2.5].

3.1.3.

Reglas con marcos o guiones

La mayor parte de las herramientas que implementan sistemas expertos de inferencia basada en reglas incluyen en un modo u otro algunos aspectos de los sistemas de representacin de marcos o guiones. Lo cual dara lugar a esquemas de inferencia hbridos. Lo habitual es que estos sistemas incorporen varios mecanismos de inferencia para tratar diferentes aspectos de la representacin. En el apartado de extensin de conocimientos de este tema se indican varias herramientas ms que incorporan varios tipos de inferencia por reglas con objetos,

3.2 Razonamiento basado en casos

19

marcos, guiones, etc. Sobre la inferencia basada en marcos y guiones se pueden ver las secciones [MDGBD95, sec. 8.2 y 8.3.3]. Un ejemplo tpico de mezcla de mecanismos de inferencia con reglas y con posibilidades de marcos es M IKE http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/expert/ systems/mike/0.html (est comentado en el apartado de extensin de conocimientos del primer tema, pg. 6, de esta gua) y otras herramientas posteriores derivadas de M IKE. La herramienta de desarrollo para sistemas expertos, C LIPS http://clipsrules.sourceforge. net/, proporciona un entorno completo para la construccin de sistemas expertos basados en reglas y objetos. Este sistema, implementado en lenguaje C, es muy utilizado en la industria y acadmicamente, ya que es de libre distribucin. Tambin existe el mdulo P Y C LIPS para integrar C LIPS dentro de P YTHON http: //pyclips.sourceforge.net/

3.2.

Razonamiento basado en casos

El razonamiento basado en casos (case based reasoning o CBR en ingls) es un proceso de tipo inductivo, que trata de obtener reglas o principios generales implcitos a partir de ejemplos individuales. Habitualmente a este proceso tambin se le denomina aprendizaje basado en casos, al menos la primera fase de preparacin o extraccin cuando se considera diferente que la fase de respuesta o aplicacin a un problema). Sobre el razonamiento basado en casos se puede ver un apartado dentro de la seccin [MDGBD95, sec. 10.3.4] de aprendizaje por analoga. Este tipo de inferencia se basa en la asociacin de caractersticas de muchos ejemplos. Se requiere que el entorno o el dominio de aplicacin sea reducido para poder prever las posibles caractersticas relevantes que despus se intentarn correlacionar para obtener un caso genrico con lo que tengan en comn los casos individuales. Este tipo de razonamiento es difcil, por ejemplo, de forma muy simplicada, si tenemos varios casos de personas altas y simpticas simultneamente, podramos establecer errneamente la generalizacin los altos son simpticos ( viceversa). Como podemos ver, esta induccin no tiene porqu ser correcta y el sistema no lo podra discernir sin casos en contra. Desde otro punto de vista se puede entender que los sistemas de razonamiento basado en casos intentan resolver nuevos problemas adaptando soluciones que ya fueron encontradas para resolver anteriores problemas. Para ello se deben identicar las caracteristicas del nuevo problema y buscar las coincidencias con caracteristicas en los anteriores problemas resueltos. Si la nueva adaptacin tambin resuelve su problema se guarda la nueva informacin para futuros problemas similares. Para este tipo de aplicacin es necesario tener descritas las caractersticas de cada caso en cuanto a sus datos y a sus inferencias de resolucin. El concepto ms importante en el razonamiento basado en casos es el de la similaridad, ya que es lo que dene cuando hemos encontrado la solucin a partir de los casos previos. Habitualmente la similaridad se basa en igualdad de valores en las mismas caractersticas, aunque no siempre se requiere una igualdad estricta, sino un grado dependiendo de los rangos de la caracterstica. Adems se debe valorar la importancia relativa de las caractersticas a comparar, dndole un peso de importancia a cada una. Despus, la similaridad global del nuevo problema con cada caso anterior se evala mediante una expresin de promedio con peso entre las caractersticas. Tambin falta por aadir cmo afectan las diferencias para adaptar la solucin a partir de un caso anterior similar (pero no igual). Finalmente, si se comprueba que la solucin obtenida era correcta se debe incorporar sta a la base de casos. En la representacin de los casos se suele utilizar muy habitualemente el paradigma de orientacin a objetos. El entorno M IKE (est comentado en el apartado de extensin de conocimientos del primer tema, pg. 6, de esta gua), y otras herramientas posteriores derivadas de l, tambin incorporan ciertos mecanismos para realizar razonamiento basado en casos. En esta asignatura no se har ms nfasis sobre estos mtodos, el alumno interesado en el tema puede encontrar ms informacin relativa al razonamiento basado en casos en el apartado de extensin de conocimientos de este tema.

20

Sistemas de razonamiento o inferencia basados en reglas y en casos

Tutorial posterior
Resumen de contenidos
En este tema se han recordado los sistemas de inferencia y razonamiento ms usuales en los sistemas expertos: 1. 2. 3. 4. 5. 6. 7. Sistemas de inferencia basados en reglas. Inferencia de reglas por encadenamiento hacia adelante como proceso deductivo. El algoritmo rete como mejora de los mtodos de encadenamiento progresivo hacia adelante. Inferencia de reglas por encadenamiento hacia atrs como proceso abductivo. Relacin de la incertidumbre en la inferencia con reglas. Mezcla de representaciones con marcos o guiones en los sistemas expertos con reglas. Sistemas de razonamiento basado en casos.

Extensin de conocimientos
Los tipos de encadenamiento hacia adelante y hacia atrs tambin se describen en: [RN96, secs. 9.3 y 9.4]. Existe un entorno modular, congurable e hbrido para el desarrollo de sistemas expertos muy interesante, B ABYLON, que est implementado en LISP. Babylon incorpora mecanismos de representacin de marcos, reglas, lgica (Prolog) y restricciones. En el libro [CdPSV92] hay una extensa descripcin sobre cmo utilizar B ABYLON para desarrollar sistemas expertos y como est implementado. Se puede obtener la ltima versin, 2.3, en http://www.cs.cmu.edu/afs/cs/project/ ai-repository/ai/areas/expert/systems/babylon/. Otro ejemplo de herramienta actual que incorpora varios mecanismos de inferencia es J ESS, http://herzberg.ca.sandia.gov/jess/, que tiene un interprete de C LIPS implementado en Java. Los mecanismos de inferencia estn basados en el encadenamiento hacia adelante con el algoritmo rete y tambin con encadenamiento hacia atrs. Tiene adems posibilidades de relacionar la representacin orientada a objetos. Aunque es comercial, tiene versiones de prueba gratuitas y especiales para usos acadmicos. El sistema ES, http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/ expert/systems/es/0.html, tambin es otra herramienta para desarrollo de sistemas expertos que tambin incorpora encadenamiento hacia adelante, hacia atrs, manejo de reglas sobre conjuntos difusos y mtodos de explicacin del razonamiento. Sobre sistemas expertos se puede consultar tambin el libro [CGH97] (disponible por Internet) y [GR98] (aunque la traduccin no es muy buena). Una pgina web (en ingls) dedicada al razonamiento basado en casos que recopila abundante informacin y recursos sobre el tema es: http://www.ai-cbr.org/. Aunque ya no se actualiza, en ella todava se pueden encontrar referencias a libreras y aplicaciones software comerciales y de libre distribucin interesantes. Podemos esquematizar los sistemas de razonamiento e inferencia en funcin de la representacin de los elementos que conocemos en las relaciones causales (o los modelos que de ellas tenemos). En la tabla 3.1 se han representado de forma muy resumida los elementos de una relaR cin causal (o regla) en la forma: a c, donde a representa los antecedentes, c los consecuentes y R es la relacin causal o regla abstracta. En la columna conocido se representan los elementos conocidos y en la columna salida lo que se obtiene en cada tipo de razonamiento. En el razonamiento deductivo, para cada cada hecho que encaja como antecedente ai y la regla R obtenemos una consecuencia ci . De la misma forma, pero intercambiando antecedentes por consecuentes, sucede con el razonamiento abductivo. En el razonamiento inductivo (basado en casos) partimos de un conjunto de pares (antecedentes, consecuentes) que nos permiten extraer una regla. En la ltima lnea se incluye una sugerencia sobre posible la representacin del aprendizaje en el razonamiento causal, en el que partimos de una regla R0 y otro ejemplo (par antecedentes, consecuentes) para obtener una regla modicada R1 .

3.2 Razonamiento basado en casos

21

Tabla 3.1: Tabla de tipos de razonamiento o inferencia segn los elementos conocidos de la relacin causal. R ac conocido salida deductivo ai , R ci abductivo R, ci ai {(ai , ci )} inductivo R aprendizaje? R0 , (ai , ci ) R1

22

Sistemas de razonamiento o inferencia basados en reglas y en casos

Tema 4

Agentes inteligentes y robtica


Tutorial previo
Introduccin
Podemos considerar que agente es un sistema que sustituye a una persona para realizar una labor. El agente puede ser tanto un programa como una mquina mecnica. En este ltimo caso hablamos de Robtica que se ha considerado prcticamente desde sus inicios como un paradigma de la Inteligencia Articial. Slo ms recientemente, con la aparicin de Internet y las mejoras de comunicaciones se empiezan a considerar inteligentes los agentes software.

Relacin con otros temas


Los agentes inteligentes pueden utilizar diversos mecanismos de bsqueda, inferencia, planicacin, etc. que sean tiles para su actividad, y por tanto nos podemos encontrar mtodos que se han comentado en todos los temas anteriores. Es posible que el alumno ya haya estudiado en asignaturas anteriores (como por ejemplo Robtica, Percepcin y Control Basados en el Conocimiento, etc.) algunos elementos de robtica mvil, o que lo vaya a estudiar en asignaturas optativas de esta misma carrera (por ejemplo Robtica Perceptual).

Objetivos del tema


Este tema pretende dar una visin sobre el panorama general de los agentes inteligentes y la robtica dentro de los paradigmas propios de la Inteligencia Articial. No se pretende dar aqu todas las explicaciones en profundidad sobre el tema que se extenderan excesivamente para esta asignatura.

Gua de estudio y esquema


Se recomienda la lectura del tema para comprobar hasta comprender la estructura general de los agentes inteligentes y su relacin con la robtica. Posteriormente, se debe acudir a repasar los conceptos y mtodos, ya estudiados previamente y que sea necesario recordar. Despus, si es necesario aplicar ms a fondo alguno de los aspectos, se pueden ampliar esos puntos utilizando las referencias dadas en el apartado de extensin de conocimientos. El tema se ha dividido en tres apartados: Introduccin Agentes software Robots mviles

23

24

Agentes inteligentes y robtica

4.1.

Introduccin

El concepto bsico de agente es el de un sistema que sustituye a una persona en su interaccin con el entorno. En cierto modo el calicativo inteligente sera redundante, puesto que si sustituye a una persona en una labor debe serlo para que la sustitucin sea adecuada. Es diseo de agentes es en denitiva el objetivo de la Inteligencia Articial. La estructura de los agentes est basada en los sistemas de tipo estmulo-respuesta, en los cuales los estmulos son las entradas desde el entorno al sistema que en funcin de sus estados elabora una respuesta que enva a su entorno. Los sistemas que dan una respuesta sin contar con estados internos se denominan reactivos y suelen formar el nivel ms bajo en sistemas ms complejos. Sobre el concepto de estmulo-respuesta podemos ampliar la estructura hacia mltiples modos de funcionamiento (llamados comportamientos o modos de comportamiento) que calculan diferentes respuestas en funcin de las entradas y que pueden adems activar los cambios de modo para dar diferentes respuestas en instantes posteriores. Para que un agente tenga posibilidad de dar diferentes respuestas a las mismas entradas, debe guardar informacin relativa a estados. Estos estados pueden ser una representacin del entorno (lo que se conoce a travs de los sensores) y tambin del propio sistema. En un agente hay que considerar cules son los objetivos deseados, es decir cul es la actividad en la que sustituye a un humano, y cules son las medidas requeridas de eciencia o rendimiento en esa actividad. Estos objetivos, junto con el tipo de entorno de interaccin, los sensores y actuadores de los que dispone el agente forma la estructura para el entorno de tarea. Dependiendo de las combinaciones de estos elementos tenemos varios tipos de agente, que podemos clasicar principalmente por su entorno de interaccin (mundo real o comunicaciones software) entre robots y agentes software. A estos ltimos en algunas ocasiones tambin se los denomina robots software o softbots, e incluso bots cuando tienen tareas muy sencillas. En el primer caso (robots), por ejemplo, encajara un sistema de conduccin de un taxi (conduccin segura en carreteras con trco usando acelerador, freno, seales, ms cmaras, sonar, GPS, girscopos, etc.), un manipulador de piezas en una cadena de montaje (recogida de piezas de forma able en cinta transportadora usando motores, pinzas, ms sensores de giro, cmaras, etc.) o un sistema automtico de control en una renera (control de pureza de sustancias en la renera usando vlvulas, bombas, calentadores con termopares, detectores qumicos, etc.). En cambio en el segundo tipo (agentes software) podramos encuadrar, por ejemplo, un sistema de diagnstico mdico (para mantener sanos a los pacientes optimizando costes y utilizando preguntas en pantalla, pruebas, tratamientos con entradas por teclado, respuestas del paciente, etc.) o un tutor interactivo de ingls (para que el estudiante aprenda lo mximo posible dentro de un conjunto de estudiantes utilizando ejercicios en pantalla, sugerencias, pruebas con las respuestas por teclado, etc.).

4.2.

Agentes software

Con el auge de las tecnologas de la comunicacin se ha visto surgir la idea de agentes que realicen labores a travs de lineas de comunicacin. El tipo de labores que se pueden calicar de inteligentes van desde la bsqueda dirigida de informacin, recopilacin, coordinacin, planicacin, etc. Adems la posibilidad de que varios agentes interacten entre s ha aumentado la complejidad y las posibilidades de los sistemas agentes. Se ha tomado el concepto de agentes para los programas, puesto que su arquitectura se basa en sistemas de estmulorespuesta, comportamientos y planicacin. La diferencia est en lo que se consideran los estmulos (sensores) y las respuestas (actuadores), que en este caso son entradas y salidas a travs de canales de comunicacin. En la actualidad debido a la aparicin de Internet, con su explosivo crecimiento y complejidad, se han desarrollado multitud de sistemas de apoyo y ayuda a la bsqueda, recuperacin y clasicacin automtica de la informacin. Los sistemas ms simples se dedican a recorrer las pginas web accesibles recopilando los datos de los contenidos y almacenando ndices y clasicando la informacin y los enlaces. Los programas rastreadores pueden ser simplemente de comprobacin de cambios en pginas para dar avisos, o bien pueden reelaborar la informacin para obtener resmenes o estadsticas de los tipos de informacin encontrados. Un caso realmente espectacular por su innovacin en esta linea ha sido el buscador G OOGLE, http: //www.google.es/, que utiliza un modelo adecuado de la informacin disponible en pginas web y elabora un sistema de indexacin que permite encontrar la pgina ms adecuada indicando unas cuantas palabras relevantes sobre el tema deseado. El sistema de clasicacin de G OOGLE, llamado Pagerank, consiste en

4.3 Robots mviles

25

asignar una puntuacin ms alta a las pginas que son enlazadas desde ms sitios importantes. Este mecanismo de puntuacin es recurrente y requiere una actualizacin continua, que es realizada por un programa distribuido de recuperacin de pginas a travs de Internet llamado Googlebot. Con la misma idea de clasicacin por enlaces y coincidencias de palabras usada en Pagerank, Google ha desarrollado otro tipo de agentes, como la bsqueda de imgenes, en grupos de news de Usenet, directorio de categoras semi-automticas, etc. En especial hay uno muy interesante, se trata de un recopilador y clasicador de noticias por Internet, http://news.google.es/ (ahora est tambin en espaol). En este sistema el agente de bsqueda recorre constantemente un conjunto de pginas sobre noticias y usando su sistema de correlacin de palabras relevantes reune todas las noticias similares de cada sitio para obtener las ms relevantes en cada categora. El entorno JADE (Java Agent DEvelopment) http://sharon.cselt.it/projects/jade/ es de libre distribucin y permite la implementacin de sistemas multi-agente a travs se sistemas middle-ware (a medio camino entre software y hardware) que cumplan con las especicaciones de la FIPA (Foundation for Intelligent Physical Agents), http://www.fipa.org/, que es una organizacin que desarrolla y publica estndares para agentes software que permitan la interaccin entre sistemas agentes heterogneos. JADE proporciona un conjunto de herramientas para la fase de depuracin e implantacin. En JADE la plataforma para el agente puede estar distribuida entre varias mquinas (incluso con distinto sistema operativo) y la conguracin se controla por una interfaz grca remota. Incluso la conguracin se puede modicar en ejecucin moviendo agentes de una mquina a otra.

4.3.

Robots mviles

Cuando hablamos de Robtica o robots mviles, nos referimos a un tipo particular de agentes inteligentes en los cuales su entorno de interaccin es el entorno fsico que nos rodea con objetos materiales y tangibles. Los estmulos en este caso provienen de sensores sobre propiedades fsicas (distancia, tamao, color, sonido, intensidad luminosa, etc.) de los objetos y las posibles respuestas son actuaciones fsicas sobre ese entorno (movimiento del propio robot, desplazamiento de objetos, transformacin o modicacin del entorno, etc.). Las mayores dicultades en robots mviles provienen de la incertidumbre y el error involucrados en la transformacin de las magnitudes fsicas medidas por los sensores hasta los valores utilizados como entrada al sistema agente que controla el robot, y tambin, en menor cuanta, a la incertidumbre y error en la transformacin desde las consignas de actuacin enviadas por el agente y los resultados en el entorno. Podemos clasicar los robots en funcin de sus capacidades y de su forma. Los robots ms antiguos son los manipuladores o brazos-robot que estn anclados en un lugar jo, como por ejemplo en una lnea de montaje de una fbrica. Estos robots tienen restringidas sus posibilidades de movimiento a las uniones o articulaciones que los forman y su tipo de actuacin suele ser de un nico tipo (pinzas, soldadura, pintura, etc.). La denominacin de robots mviles se suele reservar para otro tipo de robots que se pueden desplazar de un sitio a otro utilizando diversos mecanismos (patas, ruedas, cadenas, etc.) que se suelen utilizar en diversas actividades (vigilancia, transporte, construccin, exploracin, rescate, etc.). Finalmente, existe un tercer tipo de robots que se suelen denominar humanoides ya que intentan replicar las funcionalidades de un cuerpo humano uniendo manipuladores sobre un robot mvil bpedo. Ejemplos de este ltimo tipo han comenzado a aparecer recientemente, como el robot A SIMO de H ONDA http://world.honda.com/ASIMO/. Los tipos de sensores tpicos en robtica pueden ser pasivos que reciben informacin del entorno nada ms (cmaras, micrfonos, etc.) o tambin activos si envan algn tipo de seal y analizan la reexin o rebote de esa seal contra los objetos (del tipo del sonar). Podemos dividir los sensores en tres tipos: de rango, propioceptivos y de campo. Los sensores de rango detectan la distancia desde el robot hasta los objetos cercanos y pueden ser de infrarrojos, de sonar (transductor de ultrasonidos), de lser, tctiles, etc. dependiendo del tipo de seal utilizado para la medicin. Los sensores propioceptivos detectan la posicin, orientacin o inclinacin del robot, as como otras propiedades intrnsecas al estado del robot (por ejemplo carga de batera, conguracin, etc.) y pueden ser odomtricos (recuento de avance), inerciales (girscopos) o globales (GPS, comps magntico, etc.). Finalmente los sensores de campo detectan una magnitud fsica que es propia del punto en el que se haya el robot o hacia el que se orienta el sensor (direccionales), y por tanto pueden ser de temperatura, campo magntico o elctrico, sonido (micrfonos), imagen (cmaras). Los tipos de actuadores o efectores utilizados en robtica pueden ser de diferentes tipos. En primer lugar

26

Agentes inteligentes y robtica

tenemos los que permiten cambiar la forma o postura del robot (especialmente los brazos-robot) suelen estar compuestos de un motor que acopla dos partes rgidas y permite el movimiento en un eje (o grado de libertad) por rotacin o deslizamiento hacia otra posicin u orientacin. Por otro lado, tenemos los efectores que pueden mover el robot de un sitio a otro y que suelen estar combinados para formar los movimientos, como el tipo diferencial (dos ruedas independientes con un apoyo, o bien dos cadenas independientes) o el tipo syncro-drive en el que se orientan todas las ruedas simultneamente en la direccin de avance. Los actuadores para patas son combinaciones giros o deslizamientos de partes rgidas que pueden ser movidas por motores elctricos o por sistemas neumticos o hidrulicos. Finalmente, el robot puede tener actuadores externos (no para su propio movimiento) como pinzas para sujetar objetos y herramientas o utensilios de trabajo (soldadura, pintura, extintores, aspiradores, etc.). Desde el punto de vista de la IA lo ms interesante en los robots es su forma de representar el medio en base a sus sensores y su forma de planicar las acciones para controlar sus efectores. Ambas actividades componen la tarea ms importante y compleja en robtica mvil que se denomina genricamente navegacin. Desde la traduccin de los sensores (tanto de los de rango como los propioceptores de posicin) el robot debe representar su entorno, principalmente los objetos que pueden resultar un obstculo a su movimiento (pero tambin pueden ser objetivos). Hay varias formas de representacin utilizadas habitualmente que se pueden distinguir por el grado de informacin mtrica (medidas reales de posiciones de los objetos) que se guarda. Los mtodos de rejilla dividen el espacio en el que se mueve el robot en una rejilla y cuando se detecta un objeto se marcan los puntos correspondientes en la rejilla. En cambio los mtodos por mapa en forma de grafo van creando una representacin (que puede ser ms o menos aproximada mtricamente) de los puntos topolgicos en los que el robot puede moverse. A partir de una representacin que se va obtenida en el mapa del entorno el robot debe decidir hacia dnde moverse. Para ellos debe planicar la trayectoria teniendo en cuenta las restricciones de espacio y sus propias capacidades de movimiento (y su tamao). Existen mtodos para calcular la trayectoria que evite las colisiones por medio de clculos de campos de potencial mximo o mnimo (especialmente en representaciones de rejilla), pero la mayor parte de los mtodos de navegacin se basan, en mayor o menor grado, en el recorrido de caminos en un grafo (incluso una rejilla de ocupacin es un grafo) que, como ya hemos visto en el tema 2 sobre mtodos de bsqueda, se pueden optimizar en funcin de la informacin heurstica disponible en el problema. La arquitectura de control habitual en los sistemas de navegacin de robots mviles se suele descomponer en varios niveles, dependiendo de la proximidad a los sensores, a la representacin del medio, a la planicacin o a los actuadores, y tambin dependiendo del grado de similitud con los mtodos reactivos (conexin directa entre estmulos y respuesta) o mtodos deliberativos (en los cuales se considera tambin la informacin sobre estados y comportamientos).

Tutorial posterior
Resumen de contenidos
En este tema se han presentado los siguientes aspectos sobre los agentes inteligentes y la robtica: 1. Concepto y estructura de agente inteligente. 2. Concepto de entorno de tarea como el conjunto de las medidas de rendimiento en la actividad, el entorno de interaccin, los sensores y los actuadores. 3. Agentes software como sistemas de interaccin mediante comunicaciones. 4. Tipos de robots segn su forma y funciones: brazos-robots, robots mviles, robots humanoides. 5. Tipos de sensores y actuadores en robtica. 6. Formas de representacin del entorno y planicacin de la actuacin en los robots: navegacin.

4.3 Robots mviles

27

Extensin de conocimientos
Hay una descripcin de los agentes inteligentes en [RN96, cap. 2] y sobre robtica en [RN96, cap. 25]. Tambin en el captulo [Nil01, cap. 2] se puede encontrar una referencia a los sistemas de agentes de tipo estmulo-respuesta (reactivos) y a su relacin con la robtica. Se pueden ver explicaciones ms detalladas sobre el algoritmo Pagerank utilizado por G OO GLE en http://www.iprcom.com/papers/pagerank/, en http://pr.efactory.de/ y en http://www.webworkshop.net/pagerank.html, y tambin otra explicacin ms extensa en el artculo [RS02]. Sobre robtica mvil se pueden encontrar mucha informacin y recursos en la lista de preguntas frecuentes (FAQ) de los grupos de news comp.robotics.misc y comp.robotics.research en http://www.faqs.org/faqs/robotics-faq/. Aparte del entorno de programacin y simulacin de Robots que se usa en la prctica obligatoria de esta asignatura (ver Apndice A), y de otros entornos comerciales como: http://www. cyberbotics.com/, http://www.robotbattle.com/ http://www.mindrover.com/, tambin hay otros entornos similares, aunque requieren sistemas de tipo UNIX (como GNU/Linux, etc.) y hay que compilarlos para su instalacin (salvo versiones binarias en algunas distribuciones de GNU/Linux como Debian). GNUR OBOTS, que usa Guile (un entorno tipo Scheme/Lisp), es mucho ms simple de programar, simula un solo robot (no hay combates con otros) que debe explorar un entorno con diversos elementos. La pgina web de GNUR OBOTS es: http://www.gnu.org/software/ gnurobots/. Tambin hay un entorno de competicin de robots virtuales sencillos implementado en Java llamado R OBOCODE http://robocode.sourceforge.net/. En cambio R EAL T IME B ATTLE es bastante ms complejo que R OBOCODE puesto que adems de combatir diversos robots programados en cualquier lenguaje permite denir el entorno (arena) con diversas formas y obstculos. La pgina web de R EAL T IME B ATTLE es: http://realtimebattle.sourceforge.net/. Tambin existe una competicin programando un robot en C++R OBOTS: http://www.gamerz. net/c++robots/. Finalmente hay una versin similar de competicin directa a travs de un applet de Java (en el navegador web) llamado JR OBOTS: http://jrobots.sourceforge.net/.

28

Agentes inteligentes y robtica

Apndice A

Gua de la prctica obligatoria


Como parte de la evaluacin de esta asignatura: Sistemas Informticos II es obligatorio que el alumno supere una parte prctica realizada de forma individual y segn unas condiciones muy concretas que se especican a continuacin en este documento.

A.1.

Objetivos de la prctica

La orientacin de esta asignatura, cuyos crditos son nicamente de prcticas, es hacia la aplicacin en Sistemas Basados en el Conocimiento. En el rea de la Inteligencia Articial e Ingeniera del Conocimiento, la robtica representa uno de los paradigmas ms importantes. Por este motivo, en este curso la prctica obligatoria se realizar dentro del campo de la robtica, aunque para facilitar la realizacin en cualquier sistema y la uniformidad en la evaluacin se ha elegido un entorno que utiliza el lenguaje Java. La prctica consiste en escribir un programa de control para un robot en un entorno limitado para que compita contra otros robots segn un sistema de puntuacin preestablecido y venza a unos robots concretos preestablecidos. Los criterios de valoracin se basarn en el cumplimiento de especicaciones, requisitos y funcionalidad, teniendo en cuenta la eciencia y consumo de recursos (ver la forma de evaluacin en el apartado A.7). Los objetivos didcticos (qu se pretende que el alumno aprenda al realizar esta prctica) incluyen resolver problemas con parte de conocimiento dado (otra parte puede no ser explcita) y entender los requisitos, ms la documentacin correspondiente, para un sistema informtico. Cuando se evala (en parte) haciendo competir los programas de unos alumnos con otros (ver 2 fase de evaluacin en A.7.2) se estn incluyendo elementos desconocidos parcialmente (el entorno y el dominio del problema s son conocidos). Este tipo de problemas estn ms cercanos a los problemas reales pero requieren mtodos de solucin ms propios de la Inteligencia Articial (ms heurstica, algoritmos especcos, etc.). Al mismo tiempo, al ser problemas concretos que requieren una implementacin nal, y que adems funcionen, se intenta conseguir un aprendizaje prctico sobre cmo se pueden realizar programas que utilicen mtodos de IA y de Sistemas Basados en el Conocimiento. En resumen, los objetivos de la prctica son: 1. Aprender a usar ROBOCODE: el entorno (y su documentacin), sistema de puntuacin, las restricciones, tpicas estrategias, etc. 2. Analizar los contrincantes mnimos (y buscar estrategias para contrarrestarlos. 3. Analizar otros programas y suponer estrategias habituales (y buscar para contrarrestarlas). 4. Disear, implementar y probar un programa (hasta vencer a los mnimos). 5. Analizar la solucin y probar posibles mejoras (manteniendo lo conseguido en el punto 4).

Recomendaciones generales
Para la superacin de la prctica obligatoria es imprescindible que el alumno siga estrictamente las condiciones indicadas en esta gua. Por lo tanto la primera recomendacin es la lectura detenida y completa (varias veces) de esta gua de prctica hasta que haya comprendido completamente todos los puntos. Aqu daremos algunas recomendaciones generales sobre la realizacin de la prctica. 29

30

Gua de la prctica obligatoria

Lo primero es instalar y familiarizarse con el entorno de programacin requerido (ver apartado A.2.1), leer la documentacin que se incluye en esta gua y en el propio entorno, y hacer algunos programas de prueba hasta conocer los recursos y posibilidades del mismo. Intente escribir en primer lugar y cuanto antes un programa sencillo (y la memoria descriptiva) que cumpla las condiciones requeridas para superar la prueba. De esta forma se asegura que no le falte tiempo el ltimo da para terminar de poner a punto (errores sintcticos, fallos de ejecucin, etc.) un gran programa complejo y grande. Despus, puede dedicarse a probar otras ideas ms complejas por si dan mejor resultado (para obtener mejor nota). Recuerde que en todo proyecto informtico hay que cumplir tanto las especicaciones funcionales como los requisitos temporales (plazos de entrega, formatos, etc.) y de recursos externos (pueden fallar las mquinas, las conexiones, bajas de programadores, etc.). Tambin es recomendable que empiece a escribir la memoria descriptiva (que debe acompaar obligatoriamente a la prctica, ver apartado A.5) desde el mismo comienzo de la elaboracin de la prctica, llevando un registro detallado (a modo de un diario de laboratorio) de las etapas de desarrollo y de los cambios o pruebas realizados, incluyendo los anlisis, hiptesis y comprobaciones, y tambin describiendo los programas, aparte de la prctica, escritos o usados para los ajustes, calibraciones, etc.

A.2.
A.2.1.

Material y software
Necesario

Lo nico estrictamente necesario es el entorno de programacin y desarrollo: ROBOCODE (a efectos de la prctica slo es vlida la versin indicada ms abajo) y un runtime de JAVA para ejecutarlo. Aparte de esto slo ser necesario algn programa (ver sugerencias en apartado A.6) para crear cheros comprimidos .zip para el envo nal de la prctica con los fuentes y la memoria. ROBOCODE ya incluye un editor y un compilador de Java ms el entorno de visualizacin para la ejecucin de los programas. Este entorno, desarrollado inicialmente en ALPHAW ORKS de IBM, pas a ser opensource (bajo Common Public License) en Febrero de 2005 y actualmente se desarrolla en S OURCEFORGE http://robocode.sourceforge.net/. Aunque el desarrollo estuvo parado desde 2002 hasta Junio de 2006, recientemente han sido publicadas nuevas versiones, corrigiendo errores y aadiendo nuevas funcionalidades, a raz de la reunicacin de las diferentes variantes de ROBOCODE (ROBOCODE NG, ROBOCODE SG, ROBOCODE GL y O PEN S OURCE ROBOCODE). Para utilizar ROBOCODE , los requisitos mnimos de hardware para el funcionamiento del entorno son: Procesador equivalente a Pentium-II a 400MHz (aunque puede ser algo menos, pero ms lentamente) con 64MB. de RAM (o algo menos) y unos 10MB de espacio en disco para la instalacin (ms algo de espacio temporal para la instalacin). Puede usarse en casi cualquier sistema operativo, puesto que ROBOCODE se ejecuta en JAVA. Por lo tanto, para que el entorno ROBOCODE funcione, es necesario tener instalado previamente al menos el runtime (JRE) de OpenJDK 6 (u otro entorno totalmente equivalente, como el Java SE 6 de SUN u O RACLE). Normalmente los entornos de desarrollo JDK de Java tambin incluyen un JRE adems de un compilador, y por tanto tambin seran vlidos para la ejecucin de ROBOCODE , aunque con el JRE es suciente puesto que ROBOCODE trae su propio compilador incluido. En caso de que no tengamos instalado el JRE de JAVA sera necesario instalarlo: En algunas distribuciones de Linux ya viene como paquete propio (p.ej. en GNU/Linux-Debian y en Ubuntu es "openjdk-6-jre") y por tanto, en estos casos, es preferible instalarlo mediante las herramientas de paquetes propias del sistema. Para otras versiones de GNU/L INUX (RedHat, Centos, OpenSuse, etc.) o para O PEN S OLARIS se puede descargar la versin correspondiente desde: http://openjdk.java.net/install/ . Para otros sistemas (M ICROSOFT W INDOWS, S OLARIS), o bien si no est disponible ni como paquete propio, ni en OpenJDK, siempre es posible instalar los binarios correspondientes a la versin Java SE 6 de SUN1 descargados desde: http://java.sun.com/javase/downloads/ . Por supuesto, el entorno de desarrollo (JDK), tanto en la Standard Edition (J2SE) como en la Enterprise Edition (J2EE), ya incluye el runtime (JRE) necesario, y por tanto tambin sirven para la ejecucin de ROBOCODE.
1 Aunque

SUN ha sido recientemente adquirido por Oracle, la distribucin de Java sigue estando disponible.

A.2 Material y software

31

Para plataformas de A PPLE , que ya traen JAVA incorporado, se puede actualizar (slo en caso de que sea necesario) desde: http://developer.apple.com/java/download/ . Una vez instalado correctamente JAVA , ya podemos instalar ROBOCODE. Para ello debemos: 1. Descargar el chero robocode-setup-Si2-2012-13.jar desde la carpeta Prctica obligatoria que hay dentro del repositorio o almacn de cheros (men Documentos y material) dentro del curso virtual de la asignatura. Tngase en cuenta que esa es la nica versin vlida de ROBOCODE que se utilizar exclusivamente en la evaluacin de la prctica, y que los resultados en otras versiones no tienen validez para la evaluacin de la prctica obligatoria2 . Una vez instalada la versin de ROBOCODE para la prctica hay que tener cuidado de no actualizar nunca cuando aparece una nueva versin en el sitio original, ya que Robocode lo comprueba y nos ofrece descargarla (lo cual modicara la validez para la prctica). Ver ms abajo la recomendacin para evitar la comprobacin de actualizacin automtica. 2. Ejecutar mediante JAVA el chero recin descargado (bien a travs de asignacin en la interfaz grca, o a travs de una lnea de comandos similar a: java -jar robocode-setup-Si2-2012-13.jar). 3. Seguir las instrucciones en pantalla para aceptar los trminos de la licencia y elegir el directorio de instalacin (se recomienda uno local del usuario con permisos de escritura). Cuando termina la instalacin y conguracin, ya se puede ejecutar Robocode con un mecanismo que puede variar ligeramente dependiendo del sistema, pero que esencialmente consiste en cambiar al directorio donde se instal y activar un script (robocode.sh robocode.bat) dentro de ese directorio o utilizar algn atajo (icono, men, etc.) de la interfaz grca del sistema concreto. Atencin, es muy importante que la versin de Robocode que se utilice para la prctica obligatoria NO se actualice durante el curso. Dado que Robocode incorpora ahora un sistema de comprobacin automtica de versin disponible ms reciente, hay que tener cuidado de no aceptar nunca la actualizacin. Para evitar que Robocode haga la comprobacin automtica, despus de la instalacin y despus de la primera ejecucin de Robocode, es recomendable editar el chero de texto robocode.properties que se habr creado en el subdirectorio config dentro del directorio donde se ha instalado Robocode (ver punto 3 anterior) y cambiar en la lnea que comienza por robocode.versionchecked= a una fecha en el futuro (p.ej. es suciente cambiar el ao a 2 ms). La primera vez que se edita un robot propio dentro del entorno, se ofrece usar el compilador de java detectado en el sistema (p.ej. si se tiene algn JDK de Java), pero si no se detecta (o no se quiere usar) entonces se congura para usar el compilador incluido dentro de ROBOCODE , que es una versin de ECJ (Eclipse Compiler for Java). Hay que tener en cuenta que, aunque en la evaluacin de la prctica se utilizar el compilador de O PEN JDK 6 (que acepta correctamente todos los cheros que funcionaran con la versin del compilador ECJ incluido en ROBOCODE ), todas prcticas que funcionen con ECJ sern totalmente vlidas y aceptadas. Se puede forzar una nueva deteccin del compilador de Java desde ROBOCODE entrando en la ventana del editor de ROBOCODE y elegir la opcin del men: "Compiler Options Reset Compiler" para volver a seleccionar un compilador instalado en el sistema.

A.2.2.

Recomendado

El entorno ROBOCODE ya trae incluida la documentacin propia necesaria con la descripcin de la API (Application Programming Interface) con todas las clases y mtodos utilizables. A esta documentacin se puede acceder desde el men Help de ROBOCODE , o bien directamente con un navegador de HTML en el subdirectorio javadoc dentro del directorio de instalacin. Tambin se puede acceder a la documentacin general en la pgina web de robowiki http://robowiki.net/wiki/Robocode_Basics (a esta pgina tambin se accede desde la opcin Online Help en el men Help de ROBOCODE. En esa documentacin se explica el uso del entorno grco y cmo funciona el sistema de simulacin. Es conveniente ver en especial, dentro de esa ayuda, el tutorial sobre Game Physics y el de puntuacin (Scoring) en el juego. Tambin puede ser muy ilustrativa e interesante la lista de preguntas frecuentes http://robowiki.net/wiki/Robocode/FAQ.
2 Debido a la proliferacin de versiones no equivalentes, se ha optado por jar la versin de ROBOCODE a utilizar para la prctica en una concreta. Esta versin para la prctica puede ser derivada de alguna versin distribuida en el sitio original de desarrollo con algunas modicaciones especcas para la asignatura.

32

Gua de la prctica obligatoria

A pesar de esto, tambin puede ser interesante recordar o consultar documentacin genrica sobre Java (como http://java.sun.com/javase/6/docs/, [GdJRM+ 00] y [Eck03] ) y otras fuentes de informacin sobre ROBOCODE. Existen numerosos lugares en Internet con informacin interesante, como por ejemplo un tutorial en dos partes por Sing Li en http://www.ibm.com/developerworks/java/library/ j-robocode/ con ejemplos comentados. Hay una recopilacin de enlaces interesantes y otras fuentes de informacin en: http://robowiki.net/.

A.2.3.

Opcional

Aunque el editor incluido en ROBOCODE es sencillo, se puede utilizar perfectamente para editar de forma visual (tiene coloracin de sintaxis, uso del ratn para marcar, copiar y pegar) los programas de la prctica. An as, quiz el alumno preera utilizar otro editor o entorno de programacin (como por ejemplo E CLIPSE http://www.eclipse.org/), esto es posible ya que los cheros de los robots se encuentran en un directorio accesible y se realizan en Java, slo hay que recordar que se debe aadir la librera robocode.jar al compilar. En el tutorial Using Eclipse de robowiki, http://robowiki.net/wiki/Robocode/Eclipse, se explica precisamente cmo utilizar E CLIPSE. Lo mismo ocurre con el compilador, incluido en ROBOCODE (ECJ), que se puede sustituir por otro que se preera. Aunque la evaluacin de la prctica se realizar con el compilador de O PEN JDK 6 (todos los fuentes son recompilados), la prctica se puede realizar con otro compilador que sea compatible con ECJ, pero teniendo precaucin de no utilizar elementos no estndar de JAVA 6. Puede ser conveniente comprobar la documentacin sobre especicaciones en http://java.sun.com/javase/6/docs/technotes/ guides/language/. Para la realizacin de la memoria se puede utilizar cualquier procesador de textos que tenga la opcin de exportar el documento al formato HTML estndar (ver en el apartado A.5 los requisitos del chero de la memoria). Existen depsitos de programas para robots de ROBOCODE (incluso con el cdigo fuente) para descargar y comparar. El hecho de ver otros programas realizados para este entorno puede ayudar a comprender su funcionamiento y a dar ideas sobre otras opciones. El ms conocido de estos depsitos es: http: //robocoderepository.com. Aunque se recuerda al alumno que, para esta prctica obligatoria, la copia (incluso renombrando o reordenando el cdigo) de otros robots disponibles pblicamente (o gran similitud con alguno de ellos) ser suciente para descalicar la prctica y la apertura de un expediente, tal como se indica ms adelante en el apartado A.7. Finalmente, como informacin adicional sobre el funcionamiento interno de ROBOCODE, es posible (desde febrero de 2005) ver el cdigo fuente del propio entorno ROBOCODE, a travs de la interfaz web de su repositorio SVN http://code.google.com/p/robocode/source/browse/ (o incluso descargarlo completo). Aunque conviene recordar que en la prctica para la asignatura no se permite el uso de funciones ni clases internas que no estn documentadas en la API ocial (ver apartado A.4.2), pero siempre puede ser ilustrativo el ver como est implementado un aspecto o detalle particular que puede ayudar a comprender cmo se puede usar.

A.3.
A.3.1.

Elaboracin y desarrollo del programa


Edicin, compilacin y ejecucin

Una vez instalado, congurado y probado el entorno Robocode puede comenzar a elaborar el programa objetivo de esta prctica. Para ello puede abrir el editor interno del entorno usando la opcin Editor del men Robot en Robocode. Esto crear una nueva ventana que contendr las ventanas de edicin de los cheros correspondientes a los robots que editemos. Dentro del editor es recomendable crear un robot usando la opcin NewRobot del men File del editor. El editor solicitar el nombre del robot. Aqu podramos usar cualquier nombre, pero la versin nal de la prctica (ver apartado A.4.1) requiere que el nombre sea Si2. Despus se solicita las iniciales para crear un grupo distintivo (un subdirectorio). Nuevamente se podra usar cualquier nombre pero para la prctica (vea apartado A.4.1) se requerir que este nombre sea de la forma dxxxxxxxx donde xxxxxxxx representa el nmero de DNI (sin ceros delante). Se genera automticamente un chero con una clase que extiende la clase Robot.

A.3 Elaboracin y desarrollo del programa

33

Es necesario cambiarlo por la clase AdvancedRobot que se requiere en la prctica. Una vez hecho esto podemos salvarlo con la opcin Save del men File en el editor con lo cual, despus de conrmar el nombre del directorio nuevo y el chero, se guardar con el formato y nomenclatura requerido para la prctica. En la gura A.1 se muestra un ejemplo del aspecto de la ventana del editor de Robocode despus de crear un nuevo robot para la prctica. El cdigo fuente correspondiente a este ejemplo se encuentra en el listado A.1 para mayor claridad en las siguientes explicaciones.

Figura A.1: Ejemplo de ventana del editor de Robocode al crear un robot nuevo. Listado A.1: Listado del programa nuevo creado para controlar un robot desde el editor.
package d12345678; import robocode.*; //import java.awt.Color; /** * Si2 - a robot by (your name here) */ public class Si2 extends AdvancedRobot { /** * run: Si2s default behavior */ public void run() { // After trying out your robot, try uncommenting the import at the top, // and the next line: //setColors(Color.red,Color.blue,Color.green); while(true) {

34

Gua de la prctica obligatoria // Replace the next 4 lines with any behavior you would like ahead(100); turnGunRight(360); back(100); turnGunRight(360); } } /** * onScannedRobot: What to do when you see another robot */ public void onScannedRobot(ScannedRobotEvent e) { fire(1); } /** * onHitByBullet: What to do when youre hit by a bullet */ public void onHitByBullet(HitByBulletEvent e) { turnLeft(90 - e.getBearing()); }

Una vez guardado el chero, se puede compilar el mismo desde la opcin Compile del men Compiler en el editor, que, salvo error al sustituir AdvancedRobot y si la instalacin fue correcta, debe abrir una ventana de mensajes indicando el xito de la compilacin. Ahora ya podemos probar el nuevo robot contra otros robots. En la ventana principal de Robocode elegimos en el men Battle la opcin New que nos abre una ventana de seleccin de contrincantes. En esta ventana aparecer bajo el directorio nuevo el robot recin creado Si2 que seleccionaremos y adems podemos aadir otros robots de los que vienen como muestra (en el package sample) como por ejemplo sample.TrackFire y sample.Corners. En un combate se pueden aadir tantos robots como se quiera, e incluso repetir varios del mismo robot (ver los requisitos de la prctica en el apartado A.4.3). Tambin hay que seleccionar la cantidad de asaltos (Number of Rounds). En la evaluacin de la prctica sern 10 asaltos para cada batalla de mnimos y un nmero variable de asaltos en la fase de competicin (ver ms detalles en el apartado A.7). Una vez seleccionados los robots se puede pulsar el botn Start Battle y el combate comenzar a visualizarse en la pantalla segn se desarrolla. Cuando se minimiza la ventana de ROBOCODE, la velocidad de simulacin de batallas se incrementa notablemente (puede usarse para pruebas de gran cantidad de combates) aunque entonces no se pueden visualizar los combates. Tambin se puede aumentar o disminuir la velocidad de visualizacin con el control deslizante de la parte inferior de la ventana de la batalla. Al concluir la ronda completa de asaltos se muestra una ventana con los resultados del combate. Se puede utilizar dentro de un programa la funcin System.out.println() para imprimir informacin de depuracin y monitorizar la ejecucin del programa. Todo lo que se imprime aparecer dentro de la ventana (o consola) propia del robot, que se visualiza pulsando en el botn con el nombre del robot (en el lado derecho de la ventana) durante la ejecucin de una batalla. Tambin hay disponibles algunas opciones para poner la ejecucin en pausa, o continuar paso a paso, que pueden ser tiles para depurar el comportamiento de los programas.

A.3.2.

Descripcin de las funciones bsicas

El objetivo en Robocode es construir un programa que controle un robot simulado para combatir contra otros robots controlados tambin por otros programas individuales. El entorno de programacin en Robocode proporciona una API (Application Programming Interface) cuya documentacin est accesible desde el propio entorno en el men de ayuda. Es importante consultar esta documentacin puesto que contiene la sintaxis adecuada y notas de uso de cada mtodo o clase, junto con las descripciones exactas del comportamiento de cada mtodo (especialmente importante en los clculos geomtricos y de tiempo).

A.3 Elaboracin y desarrollo del programa

35

La simulacin de Robocode se realiza asignando hilos (threads) de ejecucin a cada robot en una batalla. El control del comportamiento de nuestro robot se debe realizar implementando (o substituyendo la denicin por defecto de) los mtodos que atienden a diferentes eventos o sucesos. Por tanto, para hacer un programa en Robocode en realidad slo hay que instanciar una clase especial y redenir los mtodos apropiados de la misma. La ejecucin del programa que controla un robot se debe activar indirectamente desde dentro de Robocode, lanzando una batalla en la cual se incluya ese robot (aparecer disponible despus de haberlo compilado correctamente). La clase especial que hay que instanciar para hacer un programa vlido (para la prctica) en Robocode es AdvancedRobot. En este apartado describiremos algunas de las funciones ms importantes de esta clase, aunque muchas en realidad son heredadas de la clase ms bsica Robot. No se mencionan otras menos interesantes o poco usadas (que se pueden consultar en la documentacin), ni por supuesto las excluidas por las restricciones de la prctica (ver apartado A.4.2). Mtodos para eventos (percepcin) Hay algunos mtodos que son ejecutados cuando ocurre algn evento en el entorno de simulacin que afecta al robot. Los mtodos que se dejen sin redenir, no hacen nada por omisin en caso de que ocurra el evento correspondiente. run() Este es el mtodo principal que se ejecuta para cada robot al inicio de un asalto y que dene su comportamiento constantemente durante el asalto. Normalmente no debe terminar nunca (voluntariamente), salvo que hayamos denido todo el comportamiento en otros eventos. Por tanto, su estructura habitual debe ser un conjunto de inicializaciones, seguido de un bucle while(true){ }. onScannedRobot() Este mtodo es muy importante porque se activar en cuanto el rastreador del robot detecte a otro robot contrincante a menos de 1200 unidades de distancia, para que podamos tomar las acciones adecuadas (dispararle o huir de l). Recibe como argumento un evento que nos informa de la situacin y caractersticas del robot detectado. La estructura habitual de onScannedRobot() ser un conjunto de instrucciones para recopilar y reelaborar la informacin del robot detectado ms uno o varios condicionales para decidir las acciones a realizar. La informacin recibida como evento es del tipo ScannedRobotEvent, que tiene mtodos necesarios para obtener datos que nos indican la posicin (ngulo y distancia relativos), el movimiento (direccin y velocidad) y estado del robot detectado: getBearing(), getDistance(), getHeading(), getVelocity() y getEnergy(), ms el instante del evento (heredado de la clase Event) getTime(). onHitByBullet() Este mtodo es importante, aunque no estrictamente necesario. Se ejecuta en el momento en que nuestro robot recibe un impacto de una bala (disparada por un contrincante). Debemos tomar las acciones encaminadas a evadirnos de sucesivos disparos, pero al mismo tiempo es una forma adicional de detectar, indirectamente, al contrincante aparte del rastreo normal. En el argumento se recibe un evento del tipo HitByBulletEvent, que contiene informacin relativa al impacto (direccin relativa, fuerza del impacto): getBearing(), getPower() y al robot que dispar la bala: getHeading(), getVelocity() (que nos permiten estimar la posicin del robot que la dispar). Adems, como todos los eventos (que heredan de Event), el instante del evento: getTime(). Hay que recordar que en la prctica no se pueden utilizar las funciones de identicacin del robot a travs de la clase Bullet que devuelve getBullet() (ver A.4.2). onHitRobot() De forma similar al anterior, este mtodo es importante, porque se activa cuando colisionamos contra otro robot con lo cual lo detectamos y sabemos donde est (aunque l tambin sabr donde est el nuestro). Adems nos permite usar otra ventaja (si le hemos impactado de frente nosotros), que es embestir para recibir puntos por impacto (pero no se recupera la energa que ambos pierden por igual). El argumento que recibe este mtodo es de tipo evento, HitRobotEvent, y contiene informacin sobre la colisin. Nos informa sobre el punto de impacto (relativo al heading de nuestro robot), getBearing(),

36

Gua de la prctica obligatoria

si hemos sido nosotros los que hemos impactado, isMyFault() y de la energa del robot contra el que hemos golpeado, getEnergy(). onHitWall() En este caso, el evento que lo activa es la colisin contra una pared con indicacin, a travs de la informacin de tipo HitWallEvent recibida, sobre la direccin relativa del impacto. Con esta informacin junto con la direccin en la que estbamos movindonos, podemos estimar en qu direccin se halla la pared o calcular su posicin, para poder cambiar la trayectoria o para evitarla en el futuro. Mtodos para acciones Dentro de las funciones que denamos para los eventos podemos utilizar algunas acciones posibles que nos permitirn mover el robot y rastrear, apuntar o disparar en diferentes direcciones. ahead(), back() Ambas funciones tienen como argumento la distancia que queremos que se mueva el robot hacia adelante o hacia atrs respectivamente. turnLeft(), turnRight() Estas dos funciones se utilizan para cambiar la orientacin del robot girando en sentido antihorario y horario respectivamente y tienen como argumento los grados a girar en cada sentido. fire() Esta es la funcin utilizada para disparar una bala con la potencia (energa) dada por su argumento (el mximo es 3, si se usa algo mayor, dispara con 3). La potencia de la bala gastar proporcionalmente la energa del robot, pero tambin obtendr devuelta una energa proporcional (el triple) en caso de impacto. Adems las balas de ms potencia son algo ms lentas. El dao causado (energa perdida por enemigo) por el impacto es proporcional al cuadruple de la potencia usada (ms un extra de 2 (potencia 1) si era mayor de 1). turnGunLeft(), turnGunRight() Con estas funciones se puede girar la torreta del robot (que lleva el can y el radar) un ngulo relativo a la base del robot en sentido antihorario y horario respectivamente. No hay que olvidar que la torreta est sobre el robot y que por tanto tambin girar la torreta al girar el robot, excepto si se cambia con la funcin setAdjustGunForRobotTurn() para lo contrario. turnRadarLeft(), turnRadarRight() De forma anloga estas funciones hacen que el radar gire un ngulo relativo a la torreta en sentido antihorario y horario respectivamente. En este caso tambin hay que recordar que normalmente el radar, que est sobre el can, tambin gira al girar la torreta (o el robot), salvo que se use la funcin setAdjustRadarForGunTurn() setAdjustRadarForRobotTurn() para cambiarlo. stop(), resume() Con estas funciones se puede detener todo el movimiento del robot (avance o giros de robot, torreta y radar) y reanudarlo despus. Puede ser necesario realizarlo en caso de situaciones de emergencia, anmalas o extraas. scan() Normalmente el robot realiza automticamente el rastreo si se est moviendo o girando (el robot, la torreta o el radar). Pero en ocasiones (cuanto se para con stop() o dentro de la funcin onScannedRobot()) puede ser necesario activar esta funcin para forzar el rastreo y comprobar si se ha detectado un robot inmediatamente. Mtodos para estado del robot El simulador de los robots nos permite conocer el estado de nuestro robot en cada instante con unos mtodos propios. getHeading(), getVelocity() Nos devuelven la orientacin y velocidad actual de nuestro robot.

A.3 Elaboracin y desarrollo del programa

37

getGunHeading(), getRadarHeading() De forma anloga estos mtodos nos devuelven la orientacin de la torreta del can y del radar respectivamente. Estas orientaciones son absolutas, a pesar de que el can se mueve cuando gira el robot y el radar se mueve cuando gira el can. getEnergy() Nos informa de cuanta energa le queda al robot. Es importante controlar este valor porque cuando llega a cero signica que el robot queda inactivado (no se puede mover ni disparar) y despus de un cierto tiempo perder el asalto, si antes no le ha alcanzado un disparo o impacto del contrincante. Se debe utilizar este valor para sopesar cuanto debemos gastar en nuestros disparos y en movimiento. getGunHeat() El valor devuelto por este mtodo nos informa del estado de calentamiento del can. Hay que recordar que con cada disparo el can se calienta proporcionalmente a la energa disparada y que hasta que no se enfre (es decir, getGunHeat() devuelva 0) no podremos volver a disparar. Al inicio de cada asalto todos los caones estn a la mxima temperatura. getTime() Este mtodo nos devuelve el instante de tiempo actual medido en tics del reloj propio del simulador. Puede ser necesario utilizarlo para calcular trayectorias (con velocidad) e intervalos en sucesos. getOthers() Este mtodo devuelve un nmero que indica simplemente la cantidad de oponentes que quedan (vivos) en el campo de batalla, pero no permite identicarlos ni saber nada sobre ellos. Mtodos para control de acciones simultneas Aparte de los mtodos normales heredados de la clase Robot, en la clase AdvancedRobot tambin tenemos otros mtodos especiales para el control de las acciones simultneas o sin esperar (non-blocking) a que terminen de realizarse. setAhead(), setBack(), setTurnLeft(), setTurnRight(), setFire(), setTurnGunLeft(), setTurnGunRight(), setTurnRadarLeft(), setTurnRadarRight(), setStop(), setResume(), execute() Todas estas funciones con el nombre comenzando por set... preparan la realizacin de una accin equivalente a las funciones correspondientes sin set..., pero no la realizan hasta que se use la funcin execute(), u otra de accin normal, en cuyo momento se realizarn todas las que estuvieran pendientes. De esta forma el control del programa no espera hasta que se completen las acciones preparadas, sino que retorna inmediatamente. Estas son las funciones avanzadas ms tiles de la clase AdvancedRobot, ya que permiten realizar varias acciones simultneamente y continuar con el control del programa. getDistanceRemaining(), getTurnRemaining(), getGunTurnRemaining(), getRadarTurnRemaining() Estas funciones sirven para determinar cuanto falta por concluir de las acciones que se han preparado con las funciones anteriores y que se han lanzado (sin esperar su conclusin) con execute(). De forma aproximada (no rigurosa) cada funcin bloqueante (sin set...) podra ser equivalente a la correspondiente no-bloqueante (con set...) seguida inmediatamente de execute() ms un bucle de espera con condicin de nal get...Remaining()==0.

A.3.3.

Diseo del programa para la prctica

En todos los aspectos del diseo de la solucin hay que considerar en primer lugar que la forma de medir (o comparar frente a otros) la calidad de la solucin es la puntuacin obtenida en combates dentro del entorno de ROBOCODE. Por tanto, todos los objetivos, anlisis, tcticas y estrategias que se utilicen en la solucin deben estar orientados a que el programa obtenga la mayor cantidad de puntos en los combates contra todos los contrincantes, los conocidos de los requisitos mnimos y los desconocidos de la 2 fase de competicin. La supervivencia y puntuacin depende en gran parte de la energa del robot (ver apartado sobre Anlisis de Tcticas en la pgina 39), pero la cantidad de puntos obtenidos por un robot en una batalla es la suma de

38

Gua de la prctica obligatoria

los puntos obtenidos en todos los asaltos en los siguientes apartados (ver scoring en http://robowiki. net/wiki/Robocode/Scoring ): Supervivencia: Cada robot que sigue vivo gana 50 puntos cada vez que otro robot muere. Esto incluso si el no ha contribuido en su muerte (ni siquiera necesita haberle acertado un disparo). ltimo superviviente: El ltimo robot vivo gana 10 puntos por cada robot que muri antes que l (es decir 10 por el nmero de contrincantes). Tambin aqu sin inuencia sobre el dao causado a esos robots. Puntos por aciertos: El robot recibe un punto por cada unidad de dao que inige a un contrario con un disparo (que depende de la energa del disparo). Bonus por aciertos: Cuando un disparo mata a un contrario, el robot que acierta recibe un bonus del 20 % de todo el dao (balas o arrollamiento) que ha inigido a ese enemigo en el asalto. Puntos por arrollamiento: El robot recibe dos puntos por cada unidad de dao que inige a un contrario al arrollarle. Bonus por arrollamiento: Cuando se destruye a un contrario por arrollamiento, el robot que ha impactado recibe un bonus del 30 % de todo el dao (balas o arrollamiento) inigido a ese enemigo en el asalto. La energa que le queda al vencedor al nal de la batalla no proporciona ningn punto extra, tal como est construida la versin actual de Robocode, aunque esto podra cambiar en futuras versiones. La energa solo es la medida local para marcar cuando muere o no un robot, por eso es una caracterstica importante en el diseo de la solucin. Objetivos de la solucin El alumno no debe olvidar cul es el objetivo del programa que debe escribir: vencer a unos robots concretos segn las condiciones dadas en el apartado A.4.3. Este es el primer objetivo prioritario en el diseo del programa. Por tanto, lo primero que se debe hacer es analizar el conocimiento previo que tenemos sobre el problema. Las condiciones externas del programa estn dadas por el entorno de Robocode (ms las limitaciones dadas en el apartado A.4.2), y el cumplimento de la tarea est denido a travs de un sistema que permite la comprobacin del resultado (vlido o no y cierta informacin de la aproximacin), pero que no nos da informacin directa sobre posibles caminos hacia la solucin. Esto nos elimina o diculta posibles mtodos de bsqueda sistemtica. Aunque se han hecho intentos de disear programas para Robocode mediante algoritmos genticos (por ejemplo ver: [BBL05], [SZS05] [Eis03]), estos mtodos siempre son largos y no tienen garanta de xito. Pero nada impide en las condiciones de la prctica obtener el diseo del programa mediante una bsqueda de tipo gentico o evolutivo como, por ejemplo, http: //jgap.sourceforge.net/doc/robocode/robocode.html. Aunque siempre hay que comprobar el cumplimiento de todas las restricciones de la prctica (funciones prohibidas, etc.) en el programa diseado. Si se trata de optimizar todas las acciones posibles, hay que tener en cuenta el funcionamiento de la simulacin de ROBOCODE. (ver Game Physics en http://robowiki.net/wiki/Robocode/Game_ Physics ). Anlisis de contrincantes mnimos Una vez que nos hayamos familiarizado con el entorno de programacin y el funcionamiento del programa de simulacin, lo ms conveniente es analizar el cdigo de los programas contrincantes a los que debemos vencer. Es importante describir y analizar sus estrategias, porque hay que intentar contrarrestar las capacidades de cada uno de los contrincantes utilizando mtodos de evasin y ataque apropiados. Ya que disponemos de los fuentes de los programas contrincantes mnimos, podemos describir el problema de la prctica como un meta-problema, puesto que tenemos la descripcin en el dominio propio y en el nivel simblico3 de una solucin a otro problema (construir un programa controlador en Robocode). El problema que debe resolver la prctica es analizar esos programas y construir otro programa que los venza a todos (en melee) en las condiciones de Robocode. La parte de anlisis de esos programas es una tarea que nos permite pasar desde el nivel simblico en el dominio propio hasta el nivel de conocimiento en el dominio del observador.
3 Se

pueden recordar las deniciones de dominios y niveles en [MDGBD95, sec. 2.1 a 2.3].

A.3 Elaboracin y desarrollo del programa

39

Diseo de solucin Despus de hacer ese anlisis, ya podemos tener una parte esencial del conocimiento necesario para disear una solucin (nuevamente en el nivel de conocimiento y el dominio del observador) en forma de estrategia y tcticas individuales. Es conveniente describir en pseudo-cdigo la estrategia que queremos poner en nuestro robot. Esta descripcin se puede usar como parte de la documentacin a aadir en la memoria de la prctica (ver apartado A.5). Despus de comprobar si la estrategia es completa y correcta la podemos implementar traducindola a las funciones del programa, es decir, pasar desde esta solucin hacia el nivel simblico y en el dominio propio para obtener el programa en el lenguaje de programacin Java utilizando las funciones de Robocode. En este momento podemos realizar la comprobacin de si se cumplen, o no, las restricciones de la prctica (si realmente vence a todos los contrincantes). En caso negativo, debemos volver a analizar los resultados para obtener un nuevo diseo. Como objetivo secundario adicional, podemos considerar el mejorar el diseo para que sea ms eciente frente a otros contrincantes en varios combates y en diferentes condiciones (ver apartado A.7.2). Pero esto debe realizarse solamente cuando ya hayamos conseguido el objetivo principal, y siempre hay que comprobar que cualquier mejora aadida no haya estropeado el cumplimento del objetivo principal de vencer a los contrincantes prejados (que es una condicin necesaria para aprobar la prctica). Anlisis de tcticas en Robocode Tanto al analizar los elementos que forman los programas contrincantes mnimos, como al disear la solucin propia, debemos considerar las caractersticas de las diferentes tcticas involucradas en el entorno de Robocode. El aspecto bsico que inuye en la puntuacin es una medida denominada energa de cada robot en el combate. Todos los contendientes parten desde el mismo nivel de energa al comienzo de cada asalto. Ese nivel de energa va cambiando segn las acciones realizadas y los resultados de algunas de esas acciones. Restan energa: el movimiento, el disparo, la colisin contra las paredes o contra otros robots y recibir impactos de balas. Aumentan la energa: acertar con una bala propia en un enemigo y golpear de frente (embestir) a otro robot. Pierde el robot que se queda con energa negativa o despus de un tiempo desactivado (sin energa suciente para moverse ni disparar). Es interesante conservar y obtener toda la energa posible para permanecer en combate (disparando o arrollando) durante el mayor tiempo posible, para tener posibilidad de acumular ms puntos. Los robots ms bsicos, que son instancia de la clase Robot directamente, no pierden ninguna energa en las colisiones (por ejemplo el robot sample.Walls), pero todos los que son instancia de AdvancedRobot, tal como se exige a los enviados para la prctica, s la pierden proporcionalmente a su velocidad en el impacto con la pared. Por lo tanto una forma de medir la calidad de una tctica es valorar su inuencia en la energa del robot. Las tcticas posibles son formas de realizar acciones (moverse, rastrear, disparar) o combinaciones de ellas con un objetivo determinado. En la tabla A.1 hemos recopilado algunas posibles tcticas (descripciones muy informales) con sus ventajas o desventajas respecto a la variacin de energa y los puntos. Es recomendable que el alumno ample esta tabla con otros anlisis de tcticas que pueda identicar en los ejemplos de programas de Robocode. Otra caracterstica de las condiciones de funcionamiento es una medida denominada calor de disparo. Cada vez que se realiza un disparo se incrementa una variable (proporcional a la fuerza del disparo) que despus se va decrementando lentamente (segn una constante denida para cada batalla). Si el valor de este calor acumulado supera un umbral no se puede disparar hasta que no haya pasado tiempo suciente para que se enfre. Esta limitacin obliga a realizar una valoracin de las posibilidades de acertar en un disparo, para elegir el momento y la energa adecuados de disparo (por supuesto si hemos detectado a un contrincante). Esta valoracin debe formar parte de las estrategias que denamos para el robot. Como recomendacin general es preferible comenzar diseando programas sencillos, e ir complicndolos solamente lo necesario, puesto que otra posible fuente de prdida es el tiempo excesivo de clculo en cada turno (ver el mtodo para evento AdvancedRobot.onSkippedTurn() en la documentacin). Adems si el programa es demasiado complicado, probablemente la estrategia tendr muchos posibles puntos de fallo y no conseguir vencer sucientemente a los contrincantes mnimos para la prctica. Incluso puede perder automticamente, si se salta 30 turnos en un asalto, debido a la complejidad del clculo.

40

Gua de la prctica obligatoria

Tabla A.1: Algunas tcticas valoradas en funcin de su inuencia sobre la energa y los puntos en Robocode. Tcticas Ventajas Desventajas Moverse aleatoriamente Ser blanco ms difcil Gastar algo de energa (poca) Acercarse hacia un enemigo Facilita acertar en disparos El enemigo tambin puede acerPosible impactar de frente tar ms fcil Desplazarse lateralmente respec- Diculta siguiente disparo al to a disparos recibidos enemigo Disparar inmediatamente hacia Si acierta obtener puntos y recu- Si acierta nos detectan antes que enemigo detectado perar energa con rastreo Si falla pierde energa Rastrear ms en la direccin de Detectar enemigos para disparar Se pierden otros blancos laterales avance o golpear de frente Disparar con muy alta energa Si acierta obtiene muchos puntos Si falla se pierde ms energa y recupera ms energae Mayor tiempo de enfriamiento

A.3.4.

Detalles sobre restricciones y formas de soslayarlas

En las restricciones obligatorias para la prctica (ver en el apartado A.4.2, ms adelante, los detalles exactos) se han incluido algunas condiciones que pueden parecer un tanto arbitrarias, pero que tienen el objetivo concreto de darle ms parecido con una aplicacin real (aunque no se pretende que se parezca a la realidad), donde haya que aplicar los mtodos de IA. Un objetivo secundario es que el alumno practique a seguir especicaciones estrictamente en el desarrollo de sistemas informticos. Las restricciones de usar ciertas funciones tambin podran darse en un caso real, por ejemplo, cuando una empresa tiene adquiridos derechos o licencias de explotacin restringidos para una parte de una librera, pero no para otras partes. En algunos casos, existen mtodos aceptables (desde el punto de vista de la prctica) que permiten soslayar en parte la dicultad que puedan imponer esas restricciones. Prohibiendo usar ciertas funciones de ROBOCODE, se impide conocer las coordenadas absolutas del robot propio y los contrincantes para evitar clculos basados en posiciones conocidas. Esta dicultad se puede paliar en parte llevando registro por coordenadas relativas al punto inicial y anotando donde hay enemigos o paredes (tamao campo desconocido) cuando se detectan. S se permite conocer la orientacin absoluta y sabemos (conocimiento a priori) que las paredes forman ngulos de 90 (solo hay que distinguir colisiones contra las esquinas). Al no poder usar funciones para saber los resultados de los disparos propios, no se puede obtener directamente informacin extra sobre los contrincantes. Esa informacin hay que suponerla indirectamente por otros datos (monitorizar la energa y ver aumentos por impactos...). La prohibicin de usar cheros externos impide que el tamao de los programas aumente demasiado (la memoria es una forma de aumentar indirectamente la capacidad de clculo). A cambio se puede entrenar (incluso usando cheros) el programa, previamente a ser enviado, y despus incluir en la versin nal (sin cheros) solamente parmetros pre-calculados. Si se desean realizar muchas ejecuciones para el entrenamiento, puede ser conveniente utilizar la API de control, solamente en la versin local. Este mismo comentario sirve para otras funciones prohibidas en la prctica obligatoria. Se pueden usar en la preparacin, pruebas, diseo, entrenamiento, etc. pero se deben eliminar totalmente para la versin enviada a evaluacin, puesto en la versin nal enviada no pueden usarse esas clases (ver apartado A.4.2). La documentacin de la API de control est junto al resto de documentacin de Robocode bajo el apartado Packages: robocode.control. Aparte de esto, las variables static de la clase Robot (y AdvancedRobot) s conservan su valor entre diferentes asaltos de la misma batalla (aunque no entre batallas). No hay ninguna restriccin sobre el uso de variables static en la prctica obligatoria. Si no se permite conocer la identicacin de los enemigos (mtodos getName(), etc.), se evita que se puedan programar variantes especcas por nombre del contrincante, y tambin diculta el seguimiento de un robot nica y simplemente por su nombre (se puede seguir por su posicin estimada, etc.).

A.4 Condiciones del programa nal

41

En cambio, s se pueden usar algoritmos de deteccin por estimacin del comportamiento de los contrincantes en funcin de los datos que s se pueden obtener (velocidad, forma de movimiento, disparos recibidos, etc.), para elegir una estrategia adecuada a ese comportamiento.

A.4.

Condiciones del programa nal

Atencin, no se olvide de probar el programa nal (con el nombre y en el directorio indicados ms abajo) antes de enviarlo y asegurarse de que cumple las siguientes condiciones.

A.4.1.

Ubicacin y nomenclatura

El programa realizado en JAVA4 debe funcionar dentro del entorno ROBOCODE. Inicialmente se puede editar, compilar y probar donde se preera, pero la versin nal del robot debe estar en una clase denominada Si2, que ser obligatoriamente una instancia de la clase AdvancedRobot de ROBOCODE, en el chero principal Si2.java. Atencin: el nombre de la clase Si2 (y su chero Si2.java) debe tener la primera letra en mayscula. Todos los cheros y componentes del robot (puede haber otros cheros .java de clases usadas en Si2 si se quiere ms claridad) estarn en un subdirectorio directamente bajo el directorio robots de ROBOCODE y que debe tener obligatoriamente como nombre dxxxxxxxx donde xxxxxxxx representa el nmero de DNI (sin puntos, ni espacios, ni guiones, ni letra nal, ni ceros a la izquierda) del alumno. En caso de que el alumno se haya matriculado con un documento distinto del DNI (Pasaporte, tarjeta residencia, visados, etc.) entonces utilizar la forma pxxxxxx donde xxxxxx ser el nmero del documento (sin puntos, ni espacios ni guiones). Por ejemplo, los nombres del directorio podran ser como: d12345678 p12345. Ntese que el nombre del directorio debe tener la primera letra en minscula. Por lo tanto, todos los cheros fuente que pertenezcan a la prctica debern llevar la instruccin package dxxxxxxxx; al principio, en correspondencia con su ubicacin en el directorio correspondiente. Si se han seguido las instrucciones de ejemplo de creacin de robot dadas en el apartado A.3 el programa ya cumplir estas condiciones. En el envo a realizar como resultado de la prctica se deben incluir todos los cheros fuente (.java) escritos por el alumno, junto con la memoria descriptiva (Si2.html, ver apartado A.5) dentro del directorio dxxxxxxxx y empaquetado todo en el chero comprimido .zip correspondiente (ver apartado A.6). Especialmente para los alumnos que utilicen un entorno de edicin externo (como por ejemplo E CLIPSE), es importante que se aseguren de incluir todos los cheros fuente y la memoria dentro del subdirectorio adecuado en el chero comprimido.

A.4.2.

Limitaciones y restricciones

Adems de las condiciones mnimas indicadas, el programa controlador del robot presentado para la prctica debe estar acotado y limitado por las siguientes restricciones obligatorias: No puede depender de ningn programa ni paquete externo, excepto el runtime de JAVA y el propio ROBOCODE. Toda la conguracin del programa debe ser automtica y no podr utilizar cheros externos para almacenar informacin, ni las llamadas de interfaz grca. El programa tampoco podr utilizar ningn paquete adicional de Java excepto, naturalmente, java.lang, java.util y java.math. Tambin se permite usar las clases y funciones relacionadas con geometra (point, polygon, color, paint, graphics, etc.) de la librera java.awt (aunque estn prohibidas otras relacionadas con eventos de teclado o ratn). Si algn alumno realmente necesita cualquier otro paquete estndar de Java para su programa, debe ponerse en contacto previamente con el equipo docente para justicar la necesidad.
4 Aunque

Robocode ha empezado a soportar programas en .NET, para la prctica obligatoria nicamente se aceptarn programas en

JAVA.

42

Gua de la prctica obligatoria

El programa no puede contener ninguna referencia, denicin ni llamada a las clases de Robocode que se listan a continuacin: BulletHitEvent, BulletMissedEvent, BulletHitBulletEvent, RobotDeathEvent, RobocodeFileOutputStream, RobocodeFileWriter. Tampoco puede usar, redenir ni llamar a ninguno de los siguientes mtodos, ni los heredados de Robocode (por ejemplo, hay que recordar que AdvancedRobot hereda los mtodos de Robot, y por tanto tampoco se podrn usar en AdvancedRobot los prohibidos de Robot): Robot.getX(), Robot.getY(), RobotStatus.getX(), RobotStatus.getY(), Bullet.getX(), Bullet.getY(), Robot.getGunCoolingRate(), Robot.getBattleFieldHeight(), Robot.getBattleFieldWidth(). Robot.getName(), ScannedRobotEvent.getName(), Bullet.getName(), HitByBulletEvent.getName(), HitRobotEvent.getName(), RobotDeathEvent.getName(), Bullet.getVictim(). Robot.onBulletHit(), Robot.onBulletMissed(), Robot.onBulletHitBullet(), Robot.onRobotDeath(), AdvancedRobot.getBulletHitEvents(), AdvancedRobot.getBulletMissedEvents(), AdvancedRobot.getBulletHitBulletEvents(), AdvancedRobot.getDataDirectory(), AdvancedRobot.getDataFile(). En resumen, se trata de excluir todas las clases y mtodos relacionados con las coordenadas absolutas, tamao del campo, identicacin de contrincante, resultado de un disparo propio y uso de cheros. Para evitar confusiones, tampoco debe el alumno crear ninguna clase o mtodo propio que tenga estos nombres o muy parecidos, ni siquiera dentro de comentarios. Es importante que el alumno se asegure de que su programa no contiene ninguna llamada, ni redenicin, ni utilizacin de estas clases, porque en caso contrario es descalicacin automtica por incumplimiento de requisitos. El programa no debe utilizar ninguno de los eventos interactivos por teclado o ratn. Es decir, no puede usar ni redenir ninguna de las funciones cuyos nombres comienzan por onKey ni por onMouse, como por ejemplo: onKeyTyped(), onKeyPressed(), onKeyReleased(), onMouseMoved(), onMouseClicked(), onMousePressed(), onMouseReleased(), onMouseEntered(), onMouseExited(), onMouseDragged(), etc. El programa no debe utilizar, ni redenir ninguna de las clases ni mtodos antiguos que estn marcados en la documentacin de Robocode como deprecated (desaprobados), ni tampoco las clases internas que comienzan por un guin bajo _ (como por ejemplo _Robot, _AdvancedRobot _AdvancedRadiansRobot). Slo se prohbe el uso directo de la clase _AdvancedRadiansRobot, pero est totalmente permitido el uso de otros mtodos para radianes (...Radians() que no comiencen por guin bajo _) y que se heredan de esa clase interna en la clase AdvancedRobot. Adems, por motivos evidentes, no se pueden usar otras clases internas de control de Robocode (ni sus mtodos) como por ejemplo: BattlefieldSpecification, BattleSpecification, RobocodeEngine, RobocodeListener, RobotResults, RobotSpecification, etc. Se pueden utilizar el resto de clases y mtodos de Robocode. Tambin se pueden usar otras clases propias (en otros cheros dentro del mismo directorio del programa propio), pero esas clases deben estar completamente denidas y descritas en el directorio, y deben respetar las mismas restricciones anteriores. Todas las clases incluidas en el directorio deben haber sido escritas y desarrolladas por el alumno. Est permitido utilizar algunas partes pequeas (o ideas) copiadas de otros programas (siempre que la licencia de publicacin de estos lo permita, y se deben documentar en la memoria dando las referencias), pero el programa de la prctica debe ser sustancialmente distinto (o estar compuesto con varias partes de otros diferentes entre s). El alumno debe asegurarse, con especial cuidado, de que las partes copiadas cumplen todas las restricciones anteriores, borrando (o introduciendo en comentarios) o modicando aquellas partes que

A.5 Memoria de la prctica

43

tengan algn conicto (especialmente se debe comprobar el uso de funciones no permitidas de Robocode, etc.). Se recuerda que, segn las normas de evaluacin (ver apartado A.7), se utilizarn y valorarn solamente las capacidades de competicin segn los puntos acumulados en combates de tipo melee. Por lo tanto, en la prctica obligatoria de este curso, no se tendrn en cuenta los combates en equipo ni los vencedores individuales de cada asalto o combate, con lo cual no tiene mucho sentido (aunque est permitido, tampoco da ventajas) usar las clases TeamRobot Droid y lo relacionado con ellas.

A.4.3.

Capacidades mnimas

El programa debe ser capaz de vencer por puntuacin acumulada, al nal de una batalla de 10 asaltos de tipo melee = todos a la vez (simultneamente en todos los asaltos de la batalla) y todos contra todos = sin equipos, a los tres programas de ejemplo (incluidos en la distribucin de ROBOCODE) siguientes: sample.SpinBot, sample.Tracker y sample.Walls. Es decir, debe quedar el primero por puntos al nal de cada batalla a 10 asaltos contra los tres robots mnimos indicados. Esta condicin debe cumplirse de forma consistente y repetida como mnimo un 90 % de las veces, es decir debe ganar, por ejemplo, 90 de cada 100 batallas, ganar 18 de cada 20 batallas, etc. Es importante que el alumno lo compruebe en su propio entorno creando nuevas batallas que incluyan esos tres contrincantes (juntos) frente al programa nal de la prctica con los valores de parmetros siguientes: Tamao del campo (Battleeld size): 2000 2000 [atencin que ese no es el valor por omisin]. Nmero de asaltos (Rounds): 10 Velocidad de enfriamiento del disparo (Gun Cooling Rate): 0.1 Mximo tiempo de inactividad (Inactivity time): 450 Debe comprobarlo varias veces (en varias batallas) para asegurarse de que su programa vence (a todos en cada batalla) de forma consistente y constantemente (no fortuitamente por azar) con los parmetros dados arriba. No se requiere que el programa del alumno venza a cada uno en los 10 asaltos de la misma batalla, slo por puntos totales acumulados en la batalla, pero es mejor asegurarse de que vence por amplio margen para evitar que unas conguraciones iniciales desfavorables le hagan perder demasiados puntos. Por tanto, las estrategias usadas en las soluciones propuestas deben buscar que el robot venza por puntos en cada batalla de 10 asaltos. No es suciente que solamente quede el primero la mayora de los asaltos para garantizar que en cualquier batalla de 10 asaltos quede el primero por puntos. Se recuerda al alumno que el alcance mximo del radar del robot es de 1200, por lo tanto en un campo de 2000 2000 puede haber situaciones donde un robot no sea detectado, y entonces sea necesario utilizar estrategias de movimiento especcas (o de estimacin) para encontrar dnde estn los enemigos que faltan, eliminarlos y obtener as todos los puntos posibles. Adems, si los robots no detectan otros enemigos, es muy fcil que se llegue a la situacin de inactividad (ninguna variacin de energa) en la que todos los robots sufren simultneamente una disminucin gradual y continua de energa hasta que todos se quedan a cero (evidentemente cuenta el orden en el que se llega a cero).

A.5.

Memoria de la prctica

Se debe acompaar la prctica con una memoria descriptiva que consistir en un texto de longitud entre 2000 y 6000 palabras (sin contar los cdigos HTML). Por ejemplo, desde este punto hasta el nal del apndice de la prctica en esta gua hay poco ms de 2500 palabras y desde el principio del apndice hasta este punto hay poco menos de 7500 palabras. El texto debe explicar y describir el contenido del programa y su funcionamiento. No se debe incluir en ningn caso el listado del cdigo fuente (puesto que el mismo ya debe ir en el chero Si2.java correspondiente), salvo muy pequeos fragmentos relevantes para la explicacin. Se deben explicar, adems de la estructura general del programa, el funcionamiento, estructura y pseudocdigo de cada una de las clases, mtodos, etc. que se han denido en el mismo. El alumno debe esforzarse en redactar ordenadamente y organizar los contenidos de la memoria con una estructura adecuada de prrafos y apartados numerados en niveles.

44

Gua de la prctica obligatoria

Esta memoria se puede escribir inicialmente con cualquier procesador de textos, pero para su envo se debe convertir (exportar) obligatoriamente en un nico chero en formato HTML estndar5 (letra negra sobre fondo blanco, con fonts estndar). Los efectos decorativos extraos (coloreados, ash o blink, markee, etc.) en el formato de la memoria se valorarn negativamente. El chero HTML de la memoria no puede contener referencias a imgenes ni guras y debe ser autocontenido (estilos CSS en lnea dentro del chero). Si es necesario algn pequeo esquema, se puede dibujar con caracteres ASCII (como por ejemplo con el programa JAV E http://www.jave.de/) e incluirlo como literal entre marcas <pre> y </pre> (para que preserve el aspecto jo) dentro del HTML. Antes del envo nal de la prctica, se recomienda visualizar el chero HTML de la memoria con un navegador web que implemente bien los estndares (como por ejemplo Mozilla F IRE F OX o similares) ya que, por ejemplo, MS I NTERNET E XPLORER, o el conversor de MS W ORD (ambos en MS W INDOWS) no los implementan correctamente (se producen desajustes y fallos en la visualizacin). Para limpiar un chero HTML generado por MS W ORD se puede usar, por ejemplo, la utilidad Tidy que se encuentra en las distribuciones de Linux y de la cual se pueden encontrar binarios ejecutables para MS W INDOWS en la pgina http://tidy. sourceforge.net/#binaries. Otra opcin es usar LibreOfce http://es.libreoffice.org/ u OpenOfce http://es.openoffice.org para abrir documentos .doc y exportar a un chero HTML estndar. El chero nal con la memoria en formato HTML es el que se incluir, dentro del mismo subdirectorio donde est la prctica, con el nombre Si2.html (atencin en los sistemas tipo MS-Windows con las extensiones ocultadas, porque el nombre debe tener la terminacin .html completa, y no .htm con tres caracteres ms usual en esos sistemas). No se deben incluir cheros en otros formatos o con otros nombres. La estructura de la memoria debe ser la siguiente: 1. Datos del alumno: Nombre, apellidos y nmero de DNI (o del documento equivalente). Telfono y correo electrnico de contacto. 2. Descripcin del funcionamiento del programa realizado. Debe incluirse una descripcin general de la estructura del programa (partes, modos de funcionamiento, fases, hilos, elementos, etc.). Es especialmente interesante que se resalten los componentes o elementos ms importantes que estn relacionados con los Sistemas Basados en Conocimiento, as como los pasos dados (o programas aparte utilizados) en el anlisis realizado para disear la solucin. 3. Descripcin detallada de cada una de las clases denidas, que incluya los miembros (funciones, variables, etc.) que contiene. Para cada elemento se deben describir: nombre, utilidad, argumentos (tipo y uso) y valores retornados, pseudocdigo genrico (pero no el cdigo fuente) de la estructura. 4. Opiniones, comentarios nales y conclusiones sobre las pruebas realizadas y los resultados obtenidos. 5. Referencias bibliogrcas (aparte de la documentacin ocial) de los documentos usados en la elaboracin de la prctica. Tambin se deben incluir las referencias (bibliogrcas o URL de localizacin) a las partes de cdigo que hayan sido copiadas de otros programas pblicos de ROBOCODE (con indicacin del origen y qu parte se ha copiado, adems del lugar dnde se han usado en el programa propio y las modicaciones realizadas). Si se ha utilizado algn tipo de informacin obtenida del cdigo fuente del propio ROBOCODE, es conveniente indicar de qu parte se obtuvo (o que pruebas se hicieron para averiguarlo). No es necesario, incluso puede ser contraproducente (ver apartado A.7.3), el incluir copias literales de partes de otros documentos, en cambio s es necesario incluir las referencias (como cita bibliogrca de autor, ttulo, forma de publicacin, ao, etc.) a todos los documentos que se hayan utilizado para la elaboracin de la prctica, excepto esta misma gua y la documentacin ocial de Robocode que se sobreentienden ya utilizados.

A.6.

Forma y plazo de entrega

Solamente se aceptarn las prcticas que hayan sido enviadas correctamente en plazo y forma adecuados a las siguientes condiciones. Cualquier problema al respecto debe comunicarse al equipo docente previamente a
5 Atencin: El formato MHTML (tambin llamado MHT, MIME-HTML o Archivo Web), no es aceptable para la memoria de la prctica. Hay que tener cuidado porque algunos navegadores (Internet-Explorer de MS, y Opera) guardan las pginas HTML en ese otro formato que es distinto.

A.6 Forma y plazo de entrega

45

la nalizacin del plazo de entrega.

A.6.1.

Formato del chero a enviar

Una vez construido (y probado) el programa correcto y escrita la memoria correspondiente (en formato HTML segn apartado A.5) es necesario vericar que todos los cheros fuente (.java) y el chero de la memoria (Si2.html) estn dentro del directorio dxxxxxxxx de la prctica para poder empaquetarlos (apartado A.4.1). Se debe fabricar un chero comprimido tipo .zip de todo el directorio dxxxxxxx de la prctica (hay que incluir el propio directorio en el empaquetado), que preserve la estructura de directorios y que incluya todos los cheros (.java) en los subdirectorios. Para fabricar el chero comprimido se puede utilizar cualquier programa compresor compatible con el formato .zip: Las plataformas de tipo GNU/L INUX traen ya incluidos como paquetes varios programas gestores de archivos comprimidos para fabricar cheros tipo .zip (como por ejemplo leroller en entorno grco G NOME, ark en entorno grco KDE, etc.). Para plataformas tipo MS-W INDOWS se puede usar por ejemplo algn programa libre abierto como 7- ZIP http://www.7-zip.org/ , como P EA Z IP http://peazip.sourceforge.net/ (tambin disponible para GNU/L INUX), bien la versin gratuita o de prueba de algn programa comercial cerrado como IZA RK http://www.izarc.org/ , como W IN Z IP http://www.winzip. com/. Las plataformas de A PPLE tambin traen su gestor de archivos incorporado como una opcin del men del gestor de archivos. El nombre del chero .zip es indiferente, pero se recomienda que empieze por el identicador del directorio de la prctica seguido de Si2 y, naturalmente, terminado en .zip (por ejemplo d12345678-Si2.zip), aunque para mayor utilidad y evitar confusiones se puede incluir tambin la fecha compacta (por ejemplo d12345678-Si2-20101215.zip). Conviene vericar que el archivo comprimido contiene todos los cheros necesarios para la prctica dentro del directorio con el nombre identicador correspondiente. Como mnimo debe contener los siguientes cheros: Si2.java y Si2.html dentro del directorio de la prctica (p.ej. d12345678), ms todos los otros cheros .java que formen el programa de la prctica. Todos los dems cheros de otro tipo (.class, .properties, de datos, etc.) sern ignorados (recurdese que la memoria en HTML no puede tener imgenes), puesto que para la evaluacin de la prctica se compilar de nuevo completamente cada prctica.

A.6.2.

Medio de envo del chero

El chero empaquetado, que se ha obtenido en el apartado anterior, se debe enviar nicamente a travs del formulario de la Tarea que se activar en el momento adecuado dentro del curso virtual de la asignatura. No deben enviarse por correo postal ni disquetes ni impresos, tampoco cheros por correo electrnico, ni en otros almacenes de datos por web, salvo indicacin en contra del equipo docente. El formato .zip es comprimido y solo debe contener cheros fuente (.java) y un documento en HTML, con lo cual el chero no ocupar mucho y se podr realizar el envo desde cualquier sitio (Centro Asociado, domicilio, trabajo, cibercaf, etc.) que tenga un navegador con acceso a Internet aunque sea lento. Una vez recibido correctamente el chero, el servidor permitir su descarga para poder vericar si se ha enviado correctamente (si es igual que el enviado por el alumno). Para ello es necesario entrar en los Detalles de la Tarea (o pulsar en el icono de lupa) y utilizar el botn Ver mi respuesta (si se ha enviado). La descarga de comprobacin se podr hacer siempre, incluso despus de concluido el plazo de envo. El sistema de Tareas del curso virtual permite volver a enviar una nueva versin de la prctica tantas veces como se precise dentro del plazo (ver siguiente apartado), pero solamente se conservar la ltima versin enviada antes de concluir el plazo. Para la evaluacin solo se utilizar la ltima versin que se haya almacenado en la Tarea correspondiente.

46

Gua de la prctica obligatoria

A.6.3.

Plazo de envo

El plazo improrrogable antes de cada convocatoria para el envo del chero, en el formato y el medio indicado anteriormente, es el siguiente: Convocatoria ordinaria de Febrero: el servidor recibir cheros desde el da 11 de Enero de 2013 hasta el da 25 de Enero de 2013 (hasta las 23:55h., hora peninsular) inclusive. Convocatoria extraordinaria de Septiembre: el servidor recibir cheros desde el da 16 de Julio de 2013 hasta el da 1 de Septiembre de 2013 (hasta las 23:55h., hora peninsular) inclusive. [Aviso: vase al nal de la seccin A.7.2 las diferencias de evaluacin de la convocatoria de Septiembre]. Tenga en cuenta que el ltimo da puede haber saturacin en el servidor (o puede tener problemas de red, etc.), por tanto se recomienda no esperar al ltimo momento para el envo. Es mejor realizarlo un poco antes para tener margen de actuacin en caso de problemas (por ejemplo diferencias horarias, etc.). Una vez concluido el plazo de envo, la Tarea del curso virtual mostrar el texto Fuera de plazo en la columna Estado de la tarea. Ese mensaje solamente hace referencia a que se ha cerrado el plazo, pero aparece as independiente de que se haya enviado o no la prctica. Para vericar si la prctica est enviada se debe comprobar si aparece el botn Ver mi respuesta dentro de los Detalles de la Tarea.

A.7.

Evaluacin de la prctica

Las prcticas enviadas sern evaluadas teniendo en cuenta los criterios enunciados en los objetivos. La evaluacin global de la asignatura se describe en el apartado Evaluacin en la pgina X (al principio de esta gua). En primer lugar, se recuerda a los alumnos el carcter individual y personal de la prctica y por tanto, el equipo docente tomar las medidas necesarias para comprobar, con los medios automticos y manuales que estime oportunos, la originalidad de la prctica remitida comparndola con todas las dems prcticas (en ambas convocatorias o de cursos anteriores) y con los programas de Robocode disponibles pblicamente en cualquier sitio. No se debe enviar el programa usado en la prctica (ni siquiera el .class, pues existen descompiladores) a los repositorios ni concursos pblicos (al menos hasta despus de evaluada la prctica) para evitar confusiones sobre la originalidad de la misma. Tampoco es recomendable enviar partes sustanciales de la prctica a otros alumnos o a los foros de la asignatura por el mismo problema (todas las prcticas similares entre s seran invlidas). En caso de que se detecte la copia (excepto lo indicado en el penltimo prrafo del apartado A.4.2), o equivalencia, o un grado de similitud elevado, incluso teniendo en cuenta cambios de nombres, comentarios y de reordenacin en el cdigo fuente, de una prctica con otro programa, o en la memoria descriptiva, se informar al Servicio de Inspeccin de la UNED para la apertura de un expediente (por supuesto, adems de considerarse la prctica como no superada).

A.7.1.

Mnimo para superar la prctica

En la primera evaluacin directa de mnimos, recibirn 4 puntos (por tanto la parte prctica estar aprobada en este curso) solamente las prcticas que cumplan todos los siguientes requisitos y especicaciones funcionales: Enviada correctamente en el plazo y la forma indicadas en esta gua [ver apartado A.6]. Se ha incluido la memoria descriptiva correspondiente (segn apartado A.5). No contiene llamadas a procesos, clases o mtodos excluidos en el apartado A.4.2 de esta gua. Compila sin errores y funciona correctamente como controlador de un robot dentro del entorno ROBO CODE en la versin especca jada para la evaluacin de esta prctica. Es capaz de vencer a los contrincantes mnimos en las condiciones indicadas en el apartado A.4.3 de esta gua. Las prcticas que no superen alguno de estos puntos no podrn pasar a la siguiente fase y recibirn una nota menor de 4 puntos que depender de cul de los requisitos falle primero en el proceso ordenado de vericacin. Es decir que la parte prctica que no cumpla alguno de los requisitos se considerar suspensa. Cuando se trate

A.7 Evaluacin de la prctica

47

de la convocatoria ordinaria de Febrero los alumnos que no hayan superado la prctica (o no la hayan presentado en Febrero) podrn volver a presentarse en Septiembre con las mismas condiciones mnimas. Para realizar estas comprobaciones se utilizarn nicamente los fuentes (*.java) que sern recompilados. Segn las restricciones del apartado A.4.2, en el directorio de la prctica no debe haber otros cheros compilados (.class) sin sus fuentes correspondientes, puesto que sern borrados antes de hacer la recompilacin.

A.7.2.

Puntos de competicin

Para valorar los aspectos de los mtodos de Inteligencia Articial y SBCs utilizados, las prcticas que hayan superado los mnimos (y por tanto ya estn aprobadas) entrarn en una fase de comparacin con las dems prcticas para clasicarlas en funcin de su eciencia. Segn su puesto de clasicacin en la competicin recibirn entre 0 y 5,5 puntos ms a sumar a los 4 puntos que ya tenan al superar los mnimos. Para esta clasicacin se realizar una competicin6 en la cual todos los robots competirn contra los dems en batallas de varios asaltos contra un nmero de contrincantes simultneo no prejado (combates tipo melee = todos a la vez y sin equipos) en un campo de tamao desconocido y parmetros (velocidad de enfriamiento de disparo y tiempo de inactividad) desconocidos. Las batallas sern de varios contrincantes a la vez pero, evidentemente, no de todos los robots (de las prcticas presentadas) a la vez. En cada batalla se elegirn aleatoriamente los parmetros que se usarn durante todos los asaltos de la misma. La cantidad de asaltos de cada batalla ser igual a 3 ms la cantidad total de contrincantes que participen en ella y que se elegir tambin aleatoriamente (entre 2 y 7) para cada batalla. El tamao del campo de batalla ser aleatorio pero proporcional al nmero de contrincantes que participen, y en general grande (ms de las 1200 unidades de alcance del radar). El resto de parmetros (enfriamiento y tiempo de inactividad) se elegirn de forma aleatoria e independientes del nmero de contrincantes, pero tambin se mantendrn iguales durante los asaltos de la misma batalla. Esta variabilidad en las condiciones desconocidas contribuir a distinguir los programas que utilicen tcnicas de Inteligencia Articial que les hagan ms verstiles. Adems de las prcticas remitidas por los alumnos, el equipo docente incluir entre los participantes de esta liga otros programas avanzados (de los disponibles en la red o elaborados propios) para elevar el nivel de las competiciones. La cantidad de estos robots aadidos ser mnima, con lo cual la mayora de robots en competicin sern los de otros alumnos que han superado la primera fase contra los mnimos y deben cumplir las restricciones impuestas para la prctica, por tanto sus estrategias estarn inuidas por estas condiciones. Al inicio de la competicin se asignar a cada robot un ndice de puntuacin igual a 0,5. Este ndice de puntuacin se ir modicando cada vez que el robot participe en una batalla. Las agrupaciones de robots para cada batalla se elegirn aleatoriamente (favoreciendo que el nmero de veces que cada robot entra en algn grupo sea similar para todos). Despus de una batalla se asignarn nuevos ndices de puntuacin a cada robot, dependiendo de los valores anteriores de los ndices de los participantes en esa batalla y de la puntuacin total (suma en todos los asaltos) obtenida por los participantes. La frmula de modicacin de ndices ser la siguiente7 pi ri := (1 i ) ri + i rj pj donde ri es el ndice de puntuacin del robot i, pi son los puntos totales obtenidos en la batalla por el robot i, los sumatorios se extienden a los n contrincantes que participan en la batalla, y i es un coeciente de reparto que depende de bi , que es el nmero de batallas anteriores en las que ha participado el robot i, y del nmero estimado total de batallas B en las que participarn todos los robots de la competicin (este nmero se elegir sucientemente grande para garantizar que cada robot participa en alguna batalla con cada uno de los dems). El coeciente de reparto ser: B i = bi + B que variar desde 1 en la primera batalla hasta 0,5 (aprox.) en la ltima batalla. As se pondera que el ndice de puntuacin anterior es representativo de ms batallas segn avanza la competicin.
6 Tanto en esta competicin como en la comprobacin de requisitos del apartado A.7.1, se utilizar la versin de Robocode disponible

para descarga desde el curso virtual de la asignatura. 7 Esta frmula es una versin general, muy parecida a las utilizadas en las clasicaciones de tipo ELO en ajedrez, donde cada participante incrementa su ndice en cada enfrentamiento en proporcin a la diferencia de nivel respecto a sus contrincantes y a los resultados de la partida, poniendo en juego (apostando) una parte de su ndice a repartir con los dems.

48

Gua de la prctica obligatoria

Al nal de la competicin, cada robot tendr un ndice de puntuacin (ri ) que reejar la proporcin promedio de puntuacin que obtendra relativa a los dems. La nota adicional obtenida por los alumnos en esta fase ser proporcional a ese ndice de puntuacin (aunque fuera negativo, los puntos de nota a sumar siempre sern 0) de forma que al robot de mximo ndice le correspondern 5,5 puntos ms en esta fase (a sumar a los del apartado A.7.1) y el de menor ndice no obtendr ningn punto en esta fase (se quedar con los obtenidos en la fase anterior de mnimos). En la convocatoria extraordinaria de Septiembre se seguir el mismo procedimiento, salvo que en la liga de competicin se incluirn tambin todas las prcticas que superaron los mnimos en la convocatoria ordinaria de Febrero (aunque estos no vern modicada su nota anterior), que de esta forma inuirn en la clasicacin de los que se presenten en Septiembre. Los resultados nales de la competicin se publicarn despus del plazo de correccin de exmenes de cada convocatoria en el curso virtual de la asignatura.

A.7.3.

Puntos extra del equipo docente

Adicionalmente a la puntuacin obtenida en las dos fases anteriores, el equipo docente podr aadir puntos extra en la revisin manual detallada de los clasicados, si considera que el trabajo (programa fuente y descripcin en la memoria) tiene mayor calidad (respecto al promedio del resto de los alumnos) e incluye aspectos relevantes o interesantes en representacin del conocimiento o de SBCs. Se valorar principalmente la utilizacin real y efectiva de mtodos de solucin relacionadas con SBCs y una adecuada modelizacin y representacin del conocimiento para resolver el problema. Tambin se valorar positivamente que la estructura del cdigo fuente y de la memoria sea clara y adecuada (no es relevante el aspecto o decoracin visual superua). Se tendr en cuenta la originalidad de los mtodos usados en la solucin. En la evaluacin de la memoria se tendr muy en cuenta si se han copiado literalmente trozos de otras memorias de prcticas de cursos anteriores, o de otros documentos (sobre todo sin citarlos como referencia). Estos casos con partes copiadas se valorarn negativamente. En los casos extremos, donde la copia de otras memorias sea muy extensa, puede ser causa para obtener una calicacin de suspenso en la prctica (con la consiguiente apertura de expediente acadmico por copia), independientemente de los resultados obtenidos por el programa del robot en las otras fases. El total de puntos extras asignados por el equipo docente a una prctica podra ser negativo en casos excepcionales, como por ejemplo, si se detecta que la descripcin de la memoria no se corresponde con el cdigo fuente del programa enviado o no lo describe correctamente, o si no hay absolutamente ninguna parte original desarrollada por el alumno, etc.

Bibliografa
[BBL05] Nick Burns, Mike Bradley, and Mei-Ling L. Liu. Applying Design Patterns in distributing a Genetic Algorithm Application. In 2005 International Conference on Software Engineering Research and Practice (SERP05), Las Vegas, Nevada, June 2005. http://www.csc. calpoly.edu/~mliu/papers/serp05.pdf. Thomas Christaller, Franco di Primio, Uwe Schnepf, and Angi Voss, editors. The AI Workbench BABYLON: An Open and Portable Development Environment for Expert Systems. Academic Press, 1992. E. Castillo, J.M. Gutirrez, and A.S. Hadi. Sistemas Expertos y Modelos de Redes Probabilsticas. Academia de Ingeniera, Madrid, 1997. La edicin en castellano se puede descargar desde http://personales.unican.es/gutierjm/BookCGH.html. F. J. Dez. Introduccin al Razonamiento Aproximado. Libro de texto (apuntes), Dpto. Inteligencia Articial - UNED, 1998. http://www.ia.uned.es/personal/fjdiez/ libros/razaprox.html. Bruce Eckel. Thinking in Java. Prentice Hall, 3 edition, 2003. http://www.mindview. net/Books/TIJ/. Jacob Eisenstein. Evolving Robocode Tank Fighters. Memo AIM-2003-023, MIT AI Lab, 2003. http://www.cc.gatech.edu/~jeisenst/papers/robocode.pdf.

[CdPSV92]

[CGH97]

[De98]

[Eck03] [Eis03]

[FGGBMM98] Severino Fernndez Galn, Jess Gonzlez Boticario, and Jos Mira Mira. Problemas Resueltos de Inteligencia Articial Aplicada: Bsqueda y Representacin. Addison-Wesley, 1998. [FMD03] J. L. Fernndez, A. Manjarrs, and F. J. Dez. Lgica Computacional. Libro de texto (apuntes), Dpto. Inteligencia Articial - UNED, Madrid, 2003. http://www.ia.uned.es/ personal/fjdiez/libros/libro-logica.html. Javier Garca de Jaln, Jos Ignacio Rodrguez, Iigo Mingo, Aitor Imaz, Alfonso Brazlez, Alberto Larzabal, Jess Calleja, and Jon Garca. Aprenda Java como si estuviera en primero. ESTI Industriales de San Sebastin - Univ. Navarra, 2000. http://mat21.etsii.upm. es/ayudainf/aprendainf/Java/Java2.pdf. Joseph Giarratano and Gary Riley. Sistemas expertos: Principios y programacin. International Thomson Editores, 1998. Jrg Heitktter and David Beasley. The Hitch-Hikers Guide to Evolutionary Computation. Faq for comp.ai.genetic, 2001. http://www.etsimo.uniovi.es/pub/EC/FAQ/www/. J. Mira, A. E. Delgado, J. G. Boticario, and F. J. Dez. Aspectos Bsicos de la Inteligencia Articial. Sanz y Torres, 1995. Nils J. Nilsson. Inteligencia Articial: Una nueva sntesis. McGraw-Hill, 2001. Peter Norvig. Paradigms of Articial Intelligence Programming: Case Studies in Common Lisp. Morgan Kaufmann, 1992. http://www.norvig.com/paip.html. 49

[GdJRM+ 00]

[GR98] [HB01] [MDGBD95] [Nil01] [Nor92]

50

Bibliografa

[PS96]

Anselmo Prez Serrada. Una introduccin a la Computacin Evolutiva. Informe tcnico, E.T.S.I. Industriales - Univ. de Valladolid, 1996. http://www.etsimo.uniovi.es/ pub/EC/EA/papers/intro-spanish.ps.gz. E. Rich and K. Knight. Inteligencia Articial. McGraw-Hill, 1994. S. Russell and P. Norvig. Inteligencia Articial: Un enfoque moderno. Prentice Hall, 1996. http://aima.cs.berkeley.edu/. Chris Ridings and Mike Shishigin. PageRank Uncovered. Informe tcnico, 2002. http: //www.voelspriet2.nl/PageRank.pdf. Y. Shichel, E. Ziserman, and M. Sipper. GP-Robocode: Using genetic programming to evolve robocode players. In M. Keijzer, A. Tettamanzi, P. Collet, J. van Hemert, and M. Tomassini, editors, Proceedings of 8th European Conference on Genetic Programming (EuroGP2005), volume 3447 of Lecture Notes in Computer Science, pages 143154. SpringerVerlag, 2005. http://web.archive.org/web/20070204160220/http://www. cs.bgu.ac.il/%7Esipper/papabs/eurogprobo-final.pdf. Kim W. Tracy and Peter M. Bouthoorn. Object-Oriented Articial Intelligence, Using C++. W H Freeman, 1997. http://www.neiu.edu/~kwtracy/ooai-book/. B. J. Wielinga, A. T. Schreiber, and J. A. Breuker. KADS: A modelling approach to knowledge engineering. Knowledge Acquisition, 4(1), 1992. Special issue The KADS: approach to knowledge enineering.

[RK94] [RN96] [RS02] [SZS05]

[TB97] [WSB92]