Autorizada la entrega del proyecto del alumno/a Alfredo Gil Mira. EL DIRECTOR DEL PROYECTO Jose Ángel Olivas Varela

Transcripción

1 Autorizada la entrega del proyecto del alumno/a Alfredo Gil Mira EL DIRECTOR DEL PROYECTO Jose Ángel Olivas Varela Fdo.:... Fecha: / / Vº Bº del Coordinador de Proyectos

2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA SEAH: SISTEMA EXPERTO ASISTENTE PARA HATTRICK AUTOR: DIRECTOR: ALFREDO GIL MIRA JOSE ÁNGEL OLIVAS VARELA MADRID, JUNIO 2007

3 SEAH: SISTEMA EXPERTO ASISTENTE PARA HATTRICK Autor: Gil Mira, Alfredo Director: Olivas Varela, Jose Ángel Entidad Colaboradora: ICAI Universidad Pontificia Comillas RESUMEN DEL PROYECTO Hatrick es un juego de estrategia online y gratuito, que permite realizar la función de manager de un club de fútbol. Para poder realizar una correcta gestión del club, el dueño de un club debe conocer muy bien las características de los jugadores para poder realizar la mejor alineación de cara a la disputa de cada encuentro. Este proyecto consiste en el desarrollo de una aplicación cuyo propósito principal es que sirva de ayuda a cualquier usuario de hattrick para poder clasificar los jugadores de su equipo y seleccionar la mejor alineación posible para cada partido que tenga que disputar. Por otro lado, la aplicación permite tanto crear manualmente un equipo con todos sus jugadores, como cargar esa información de un fichero xml, reduciendo el coste en tiempo del alta de un equipo. Así mismo, la aplicación también permite que se carguen todos los datos históricos de un equipo que se obtienen en formato xml para que sean usados posteriormente por la aplicación a la hora de obtener una alineación ideal. Por tanto, la aplicación SEAH (Sistema Experto Asistente para Hattrick) ofrece las siguientes opciones: Gestión de equipos en hattrick: altas, bajas o modificaciones. Gestión de jugadores de un equipo Clasificación de los jugadores: permite que el usuario clasifique por demarcaciones a los jugadores de su equipo. i

4 Calcular la mejor alineación de un equipo basándose únicamente en los valores de las habilidades de un jugador Calcular la mejora alineación de un equipo basándose no sólo en los valores de las habilidades de un jugador, sino teniendo en cuenta todos los partidos disputados anteriormente por ese equipo. Así, para la realización de este sistema se han hecho uso de las técnicas tradicionales de ingeniería del conocimiento, como las técnicas del llamado proceso de descubrimiento de conocimiento en bases de datos (KDD: Knowledge Discovery in Databases), que incluye técnicas de Data Mining. Como se explica más detalladamente en el desarrollo del proyecto, para la parte de clasificación de los jugadores por demarcación en el terreno de juego, y para la realización de la mejor alineación basándose únicamente en los valores de las habilidades de los jugadores, se ha usado la ingeniería del conocimiento desde el punto de vista tradicional y ésta consta de las siguientes fases: Adquisición del conocimiento Representación del conocimiento Razonamiento Para la adquisición del conocimiento se ha hecho uso de la entrevista, empezando por entrevistas abiertas para poder acotar un poco mejor el problema y pasando más adelante a las entrevistas estructuradas para poder obtener la base de conocimiento. Después de esta fase se vio claramente que la mejor representación del conocimiento era el de los marcos, así se obtuvieron marcos para la clasificación de jugadores según su demarcación y para la clasificación de los jugadores para obtener la mejor alineación. Por otra parte, para la obtención de la mejor alineación teniendo en cuenta no sólo los valores de las habilidades de los jugadores, sino los resultados obtenidos por los jugadores en los partidos ya disputados, se ha desarrollado un proceso de descubrimiento de conocimiento en bases de datos (KDD). Este proceso como se puede ver en el desarrollo del proyecto cuenta con las siguientes fases: ii

5 Aprendizaje del dominio de la aplicación Creación de un subconjunto de datos objetivo Filtrado de datos y preproceso Proyección y reducción de datos Data Mining Interpretación En este caso hemos partido de todos los datos históricos de los equipos obtenidos en formato xml por otra aplicación gratuita que proporciona el juego, que permite extraer toda la información histórica de las partidas disputadas con anterioridad. Con todos los datos históricos de las partidas anteriores se han ido aplicando las distintas fases del proceso de descubrimiento de conocimiento en bases de datos para obtener de una forma estructurada y aplicada al problema los valores obtenidos en los jugadores a lo largo de su carrera. Con estos resultados el sistema utiliza algoritmos de ranking y resumen para interpretar los resultados y aplicarlos al proceso ya realizado con la ingeniería del conocimiento tradicional y presentar la mejor alineación posible teniendo en cuenta tanto los datos históricos de los jugadores como los valores en las habilidades de cada jugador. Todo el sistema se ha desarrollado con aplicaciones gratuitas para no incrementar el coste económico del proyecto. Por ello, se ha desarrollado una aplicación Web con tecnología J2EE, con MySql como gestor de bases de datos y con el tomcat de Apache como servidor de aplicaciones. Así se ha obtenido una interfaz amigable para el usuario. Durante todo el desarrollo del proyecto se han ido realizando pruebas de validación con el experto para corroborar que los resultados que se han ido obteniendo eran correctos desde el punto de vista del experto. Se pude decir que estas pruebas han sido plenamente satisfactorias y que se ha conseguido el objetivo que se esperaba; y lo que es más, actualmente los expertos que han intervenido en este sistema están usando el sistema para realizar las alineaciones en los partidos de hattrick. iii

6 SEAH: HATTRICK ASSISTANT EXPERT SYSTEM Author: Gil Mira, Alfredo Director: Olivas Varela, Jose Ángel Colaboration Entity: ICAI Universidad Pontificia Comillas ABSTRACT Hattrick is a free online strategy game, which allows you to do the job of a football manager. To be able to do a proper management of the club, the club owner must know pretty well the abilities of his players in order to present the best possible line-up for each football game. This project, consist in the development of an application which its main objective is to assist any hattrick player to be able to classify the players in a team and to select the best possible line-up for each game to play. On the other hand, the system permits you to create a team with all its players manually, or to populate that information from xml files, reducing the costs in time for the registration process for a particular team. What is more, the system also permits you to populate all the historical data from a team in xml format into the database, so the system can use this data to obtain the best possible line-up. Therefore, the SEAH system (Sistema Experto Asistente para Hattrick, or, in English, Hattrick Assistant Expert System) offers the following features: Hattrick team management: registrations, deletions, modifications. Player management for a team. Player classification: allows you to classify players based on field positions. Calculate the best possible line-up for a team only based on the values of the abilities of a player. iv

7 Calculate the best possible line-up for a team based not only on the values of the abilities of a player, but also taking into account all the games previously played by that team. So, for the system development, it has been used traditional knowledge engineering techniques, but also techniques from the knowledge discovery in databases process (KDD process), which includes data mining techniques. As fairly explained throughout this project, for the player classification by field position part, and for the generation of the best line-up based only on the values of the abilities of the players part as well, it has been used knowledge engineering in a traditional fashion which consists of the following phases: Knowledge acquisition Knowledge representation Reasoning For knowledge acquisition it has been used the interview, starting by opened interviews to be able to delimit the problem a little bit and after that, moving on to structured interviews to be able to get a knowledge base. After this step, it was observed that the best way for knowledge representation was frames, so frames were used to classify players by field position and for player classification to get the best possible line-up as well. On the other hand, in order to be able to get the best possible line-up taking into account not only the player s abilities, but also the player s performance in previous matches, it has been developed a knowledge discovery in databases process. This process, as seen throughout the project, consists of the following steps: v

8 Learning the application domain Creating a target dataset Data cleaning and preprocessing Data reduction and projection Data Mining Interpretation In this case we have set the starting point at all the historical data of the team obtained in format xml by another free application that provides the game, that allows to extract previously all the historical information of the disputed games. With all the historical data of the previous matches they have been applied the different phases from the process of knowledge discovery in databases to obtain in a structured and problem appliance fashion the values obtained in the player throughout its race. With these results, the system uses algorithms of ranking and summary to interpret the results and of applying them to the process already made with the engineering of the traditional knowledge and to present the best possible line-up as much considering the historical data of the players like the values in the abilities of each player. All the system has been developed with free applications in order to not to increase the economic costs of the project. For that reason, a Web application has been developed using J2EE technology, MySql as database management system and with Tomcat of Apache for server applications. Thus a friendly interface for the user has been developed. Throughout the development of this project has been made tests of validation with the expert to corroborate that the results that have been obtained were right from the expert point of view. I could be said that these tests have been totally satisfactory and it has obtained the objective that was expected; and what is more, at the moment the experts who have taken part in this system are using the system to make the line-ups in the hattrick matches. vi

9 Índice 1. Introducción y Objetivos Introducción Objetivos Descripción del problema a tratar Definición y desarrollo del Sistema Experto Análisis de viabilidad Características de Plausibilidad Características de Justificación Características de Adecuación Características de Éxito Adquisición del conocimiento Representación del conocimiento Razonamiento (Algoritmo de Alineación Estándar) Descubrimiento de conocimiento a partir de casos históricos (KDD: Knowledge Discovery in Databases) Introducción Aprendizaje del dominio de la aplicación Creación de un subconjunto de datos objetivo Filtrado de datos y preproceso Descarte de ficheros Selección, descarte de variables y diseño de tablas Formateo de variables especiales Estrategias para manejar datos omisos Proyección y reducción de datos Transformación Elección de la función y algoritmo de Data Mining Integración del algoritmo estándar con el proceso KDD Implementación Arquitectura del sistema Evaluación

10 8. Planificación y presupuesto Planificación Presupuesto Conclusiones Grado de cumplimiento de los objetivos BIBLIOGRAFÍA REFERENCIAS WEB ANEXOS ANEXO A: Sistemas expertos A.1. Introducción A.2. Definición y características de los SE A.3. Descubrimiento de conocimiento en Bases de Datos (KDD) ANEXO B: FICHEROS XML CódigoPartido.MatchDetails.xml CódigoPartido.OwnMatchLineup.xml y CódigoPartido.OpponentMatchLineup.xml CódigoPartido.HTLive.xml Players.xml ANEXO B: MANUAL DE INSTALACIÓN ANEXO C: MANUAL DE USUARIO

11 Índice de Figuras Figura 1. Variantes de una formación Figura 2. Variantes de una formación Figura 3. Variantes de una formación Figura 4. Variantes de una formación Figura 5. Variantes de una formación Figura 6. Variantes de una formación Figura 7. Variantes de una formación Figura 8. Mapeo de la habilidad con su valor numérico Figura 9. Estructura de datos obtenida de la tabla transformación Figura 10. Función ranking para los mejores jugadores del histórico de partidos Figura 11. Función ranking para los mejores jugadores según los marcos Figura 12. Comparación de los vectores tras las puntuaciones de la función ranking. 133 Figura 13. Jugadores seleccionados tras aplicar el algoritmo de data mining Figura 14. Arquitectura funcional de SEAH Figura 15. Toma de datos de la aplicación Hattrick Forever Figura 16. Toma de datos del algoritmo estándar de SEAH Figura 17. Toma de datos del algoritmo de data mining de SEAH Figura 18. Comparativa del algoritmo de data mining de SEAH contra el algoritmo estándar y la aplicación Hattrick Forever Figura 19. Planificación. Diagrama de Gantt Figura 20. Coste del proyecto Figura 21. Arquitectura de un sistema experto Figura 22. Pasos del proceso KDD Figura 23. Instalación de Java (I) Figura 24. Instalación de Java (II) Figura 25. Instalación de Java (III) Figura 26. Instalación de Java (IV) Figura 27. Instalación de Java (V) Figura 28. Instalación de Java (VI) Figura 29. Instalación de Java (VII) Figura 30. Instalación de MySQL(I)

12 Figura 31. Instalación de MySQL(II) Figura 32. Instalación de MySQL(III) Figura 33. Instalación de MySQL(IV) Figura 34. Configuración de MySQL(I) Figura 35. Configuración de MySQL(II) Figura 36. Configuración de MySQL(III) Figura 37. Configuración de MySQL(III) Figura 38. Configuración de MySQL(IV) Figura 39. Configuración de MySQL(V) Figura 40. Configuración de MySQL(VI) Figura 41. Página principal de SEAH Figura 42. Listado de equipos vacío Figura 43. Alta manual de equipo Figura 44. Carga de de ficheros xml Figura 45. Selección del directorio de ficheros xml Figura 46. Proceso de carga de ficheros xml Figura 47. Listado de equipos Figura 48. Preparando el histórico de partidos Figura 49. Listado de jugadores sin clasificar (I) Figura 50. Listado de jugadores sin clasificar (II) Figura 51. Modificar jugador Figura 52. Menú de cabecera Figura 53. Alta manual de jugador Figura 54. Listado de jugadores clasificados (I) Figura 55. Listado de jugadores clasificados (II) Figura 56. Log de pesos de clasificación (I) Figura 57. Log de pesos de clasificación (II) Figura 58. Selección de algoritmo de alineación Figura 59. Selección del tipo de formación Figura 60. Selección del tipo de formación (I) Figura 61. Selección del tipo de formación (II) Figura 62. Alineación recomendada por el algoritmo estándar Figura 63. Alineación recomendada por el algoritmo de data mining Figura 64. Log de pesos de alineación (I)

13 Figura 65. Log de pesos de alineación (II) Introducción y Objetivos 11

14 1.1. Introducción La capacidad de hacer que los ordenadores imiten el comportamiento humano y que actúen de forma inteligente siempre me ha parecido una de las áreas más atractivas de la informática. Y conforme iba cursando las diferentes asignaturas relacionadas con la inteligencia artificial el interés iba en aumento. Así, a la hora de elegir el tema del proyecto fin de carrera, la Inteligencia Artificial fue desde el primer momento una de las áreas con más posibilidades. En concreto, los Sistemas Expertos que es el campo de entre los que componen la Inteligencia Artificial, el cual se encarga de desarrollo de software que, mediante técnicas de inteligencia Artificial, intentan imitar el comportamiento humano para la solución de problemas en áreas especificas que requieren razonamiento. Esto se modeliza en un programa a partir del razonamiento de experto humano. Esto implica que solo en el mejor de los casos el Sistema Experto daría las mismas prestaciones que los expertos humanos. A la hora de elegir sobre que podría tratar el sistema experto surgieron varias posibilidades, pero habría que elegir un campo del que se conociesen o se tuviese acceso a varios expertos y además que fuese un campo sobre el que se tuviese interés para que no se convirtiese en un trabajo arduo y tedioso. Era importante en primer lugar el acceso a varios expertos, para así no limitar al sistema experto al criterio de una sola persona y poder contrastar distintas resoluciones al mismo problema. 12

15 Así se abrió la posibilidad de desarrollar un sistema experto capaz de realizar la mejor alineación para un juego muy popular en Internet del que forman parte en España alrededor de usuarios y que sigue ampliándose día a día. Se trata básicamente que a través de los datos de un equipo, jugadores y características de los mismos, el sistema sea capaz de realizar la mejor alineación posible con los jugadores disponibles en cada momento. Al elegir este sistema experto, se cumplían las expectativas buscadas desde un principio. Primero: Realizar un sistema experto como proyecto fin de carrera para profundizar en la implementación de un software capaz de simular un conocimiento humano. Segundo: Poder contar con un amplio número de expertos para poder contrastar el conocimiento de cada uno y poder dotar de mayor inteligencia al sistema experto. Tercero: Realizar un sistema experto que versase sobre un tema por el cual me sintiese atraído. Cuarto: Que el resultado pudiese ser usado por un amplio número de usuarios. Cumpliendo todos estos requisitos que se deseaban se podía comenzar el proceso del desarrollo de un sistema experto, el cual se puede dividir en cuatro fases: Estudio de la viabilidad de la aplicación. Adquisición y Representación del conocimiento. 13

16 Implementación de la aplicación. Validación del sistema. Por otro lado, a la hora de abordar la realización del proyecto fin de carrera, se quiso llegar un poco más allá y que no se quedase en la realización de un mero sistema experto de una forma tradicional, por tanto, se ha desarrollado un sistema experto por un lado tradicional basado en marcos, pero se ha completado con el desarrollo íntegro del proceso KDD (Proceso de descubrimiento de conocimiento en Base de Datos). Para ello se ha basado en la obtención de los datos históricos de un equipo y su análisis, para una vez analizados estos datos, mezclarlos con el sistema experto tradicional y así enriquecer enormemente tanto la aplicación como el desarrollo del proyecto fin de carrera. Sin duda, la parte más compleja y dura ha sido la adquisición del conocimiento, ya que debido a la utilización de varios expertos, el análisis de cada una de las entrevistas se multiplicaba y esto se le añadía además el proceso de puesta en común de los resultados. Esto hizo que el proceso de adquisición del conocimiento se alargara considerablemente. Pese a ello, y gracias a la colaboración de los expertos, creo que el esfuerzo mereció la pena ya que el resultado fue una base de conocimientos bastante completa que simplificó bastante tanto la representación como la implementación. 14

17 1.2. Objetivos Por tanto se puede decir que los objetivos que se esperan del proyecto son: Profundizar en el desarrollo de un proceso de KDD: se pretende desarrollar todo el proceso de Descubrimiento de conocimiento en Bases de Datos (KDD), con todas y cada una de sus fases. Una ayuda real y rápida para el jugador de hattrick: la generación de una aplicación que sirva al jugador de hattrick a conocer mejor a los jugadores de su equipo y poder sacar el máximo rendimiento de ellos en los partidos de competición Clasificación de los jugadores según sus características: que el sistema sea capaz, en función del valor de las habilidades de cada jugador clasificarlo dentro de una demarcación en el campo. Esto permitirá al jugador de hattrick saber de que demarcaciones carece dentro de su equipo. Generar una alineación en función de las habilidades de los jugadores y con una formación dada: el sistema debe ser capaz de generar la mejor alineación posible en función del valor de las habilidades de cada jugador en cada momento. 15

18 Generar una alineación basada en los datos históricos y en las habilidades de los jugadores con una formación dada: el sistema debe ser capaz de generar la mejor alineación, no sólo en función del valor de las habilidades que tienen los jugadores en un determinado momento, sino teniendo en cuenta sus actuaciones en los partidos ya disputados. A continuación, se expone el resultado de todo este proceso, junto con documentación que ayuda a comprender mejor todo el desarrollo. 16

19 2. Descripción del problema a tratar 17

20 Lo primero que cualquiera que lea este proyecto y no conozca hattrick se preguntará es, qué es hattrick? Bien, ante todo hattrick es un juego de estrategia, online y gratuito. Sintetizando mucho la esencia y desarrollo del juego, podríamos decir que se trata de un manager de fútbol a través del cual diriges tu equipo, compras jugadores, vendes, entrenas y juegas online contra otros usuarios de cualquier país. A través de tu navegador de Internet y sin tener que descargarte ningún programa alternativo, puedes realizar cualquier tipo de instrucción, cambio o simplemente charlar con cualquier otro usuario a través de mail o de los foros. Además hattrick nunca termina, ya que hay se disputan ligas continuamente y siempre hay un objetivo por el que luchar. Historia Hattrick nace en Suecia hace ya casi 10 años, el 30 de agosto de 1997, con 16 privilegiados equipos divididos en 2 grupos. Esta primera prueba es lo que hoy son más de un millón de usuarios en todo el mundo. Después de este primer paso hay un pequeño parón para poder reorganizar todos los fallos y reprogramar el juego, así más adelante hattrick reaparece con 680 equipos y con partidos de selecciones nacionales. Poco a poco la fiebre por hattrick se va extendiendo entre todos los países nórdicos y la ampliación a 1704 equipos, creación de la copa nacional y de la IV división con 128 grupos es prueba de ello. En esta reaparición para mejorar el entrenamiento de los jugadores nacieron los amistosos de los miércoles. Poco a poco fueron pasando los años y las variaciones tácticas fueron apareciendo y la introducción de variantes a la formación hizo más dinámico el juego. 18

21 A principios del año 2000 comienza la revolución europea de hattrick, después de un parón de un mes nacieron nuevas ligas como la española, finlandesa, inglesa, italiana, se consigue una ampliación a 15 calificaciones de los jugadores, además de que hattrick se mantenga en línea las 24 horas del día. La reestructuración que crea las bases y cimientos del hattrick actual se estaba fraguando, para ello se necesitaba crear un status y una jerarquía de ligas, éstas ya dejan de ser al azar y son causas de los resultados de las temporadas anteriores. Según avanza el tiempo y van aumentando los usuarios, nacen las urgencias por conseguir dinero para poder mantener todo el juego, pero para conseguirlo no rompen con su filosofía inicial de que sea totalmente gratuito, sino que nace Hattrick Supporter. Esta opción es una mejora sólo para los que decidan abonar una pequeña cantidad de dinero y recibir a cambio unos privilegios en tanto en cuanto al uso de la página, nunca en beneficio del motor del juego. En 2002 la fiebre por hattrick, va en aumento, lo que obliga a la creación de un nuevo sistema de entrenadores, un nuevo sistema de evolución del espíritu del equipo para parar algo las transferencias, la aparición de las selecciones sub-20, mejoras para los supporter, pero sobre todo la opción hattrick Live, poder ver los partidos de tu equipo en vivo y en directo, minuto a minuto. La fiebre es tal que se crean en Expekt.com las apuestas reales sobre los partidos de hattrick. 19

22 En 2004 se superan ya los usuarios activos y se crea un nuevo sistema de copa. El crecimiento de ligas no cesa, y se crean ligas tan recónditas como Al Urdon, Georgia, Andorra, también aparecen nuevos entrenamientos, se amplían las federaciones, el número de supporters, A día de hoy son alrededor de 1 millón de usuarios activos a lo largo y ancho del mundo. Se han creado más de 100 ligas nacionales y se ha traducido a 34 idiomas, llegando a lugares del mundo tales como Irak, Pakistán, Kenya, etc. El juego Es un juego más que de fútbol, de estrategia ligado al fútbol. A través de lo que tenemos como un equipo de fútbol, vamos mejorando semana a semana nuestra plantilla como entrenamiento, sin embargo esto no es tan sencillo como pueda parecer, porque tan solo podremos hacer un tipo de entrenamiento a la semana, lo que conllevará una pequeña mejora dentro de una de las habilidades de cada uno de los jugadores que juegan en la línea que estamos entrenando. Por lo cual es muy importante en el juego saber organizarse. Un buen planteamiento del entrenamiento, unas buenas compras y ventas harán que tus calificaciones generales puedan ir subiendo paulatinamente mientras tu economía esta saneada. 20

23 Para una persona que se introduce en hattrick es algo complicado comenzar a enterarse si no tiene un guía o si no se molesta en leerse las guías y demás páginas de ayuda. La paciencia es un factor importantísimo ya que es un juego lento, la evolución de los jugadores no es rápida ya que por ejemplo para subir un nivel de habilidad son más o menos 6-8 semanas reales, dependiendo del tipo de entrenamiento que estemos realizando. En hattrick sólo se juega un partido de liga a la semana, los sábados, y un partido los miércoles, amistoso o de copa. Esto hace que el entrenamiento no esté sólo en esos días, esos días tienen que ser el resumen semanal de la preparación del partido. El motor del juego tiene de base el medio del campo, pero se encuentran muchas alternativas a éste desde el tipo defensivo y jugar al contraataque o por ejemplo los entrenadores de anotación con su gran efectividad de cara a puerta. Esto hace que no haya una táctica ni un entrenamiento predeterminado que sea mejor que el resto, simplemente que haya una serie de habilidades que sobresalen sobre el resto: anotación, jugadas y defensa. Las ligas son de 8 equipos y tienen ida y vuelta, en estos 14 partidos uno se juega ascender, si queda primero, o descender, si queda en los dos últimos puestos descenderá directamente, en las ligas de V para arriba el 5º y 6º promocionan para defender o quedarse. 21

24 El beneficio económico de jugar en casa es muy grande ya que no sólo tu medio del campo tendrá un plus extra de fuerza y hará que tu equipo tenga más posibilidades de ganar, sino que también deberás conseguir el dinero suficiente a través tu estadio para cuadrar los gastos de las semanas que se juega fuera. Este es un factor importantísimo en hattrick ya que muchos de los jugadores no son capaces de asumir los gastos de fichas, mantenimiento del estadio, especialistas, con un estadio no adecuado al tamaño que el equipo de merece y así es como llegan las quiebras y puedes perder tu equipo de hattrick. El público que acude a nuestro estadio, está directamente relacionado con la cantidad de socios que tenemos (cada lunes y jueves se actualizan nuestros socios, en función a los resultados obtenidos y los patrocinadores que tenemos), el tiempo que hace, el rival que viene a nuestro estadio, Vamos a describir ahora con detalle como es un jugador de cualquier equipo de hattrick y que habilidades posé, las cuales son determinantes para saber tanto la calidad como la posición del jugador en el equipo. Un Jugador en hattrick viene determinado por las siguientes características: Nombre Edad Forma Experiencia Liderazgo Condición Portería Jugadas Pases 22

25 Lateral Defensa Anotación Balón Parado Lesión Amonestación La forma y el liderazgo pueden tener los siguientes valores: Excelente Bueno Aceptable Insuficiente Débil Pobre Horrible Desastroso El liderazgo no varía lo largo de la vida del jugador, y a mejor liderazgo mejor condición para ser el capitán de un equipo ya que sabrá organizar y mandar a los jugadores. La forma, va variando a lo largo de la vida del jugador, un jugador joven es más fácil que consiga una buena forma que un jugador mayor, y esta va variando en función de si un jugador no juega nunca, no podrá adquirir una buena forma, o si sale de una lesión necesita unas semanas para recuperar la forma y cuanto mayor sea un jugador más le 23

26 costará adquirir la forma. Además una mala forma influirá negativamente en las habilidades de un jugador. Las otras características del jugador, a excepción de la experiencia que se va adquiriendo según un jugador juegue partidos, son las llamadas habilidades propias del jugador y pueden tener los siguientes valores: Divino Utópico Mágico Mítico Extraterrestre Titánico Sobrenatural Clase Mundial Magnífico Brillante Destacado Formidable Excelente Bueno Aceptable Insuficiente Débil Pobre Horrible 24

27 Desastroso El valor de estas habilidades son las que marcan la demarcación en el campo y la calidad de cada jugador en esa demarcación. Con lo que son fundamentales a la hora de hacer la mejor alineación posible de un equipo, aunque también es necesario tener en cuenta la forma y la experiencia. Vamos a describir un poco cada una de estas habilidades que significado tiene: Condición: es una habilidad esencial para cualquier jugador que quieras poner en el centro del campo, aunque también puede influir en otras partes del campo, sin ella los jugadores se cansarán antes, y la segunda parte puede ser desastrosa para tu equipo. Portería: esta habilidad sólo influye para los porteros, a mejor portería mejor portero será, un buen portero también puede aumentar el nivel general de la defensa. Jugadas: característica esencial de todos los centrocampistas, cuanto más nivel tengan de esta habilidad nuestros centrocampistas, mayor control de balón podrá tener nuestro equipo. La posesión aumentará y con ella la posibilidad de tener más ocasiones de gol. Pases: es una habilidad secundaria, pero muy valorada en todo tipo de jugadores; en los defensas marca el nivel de contraataque que pueden darnos estos jugadores, en los medios y delanteros aportan el ataque central, y en los extremos afectan en cuanto al ataque lateral. Lateral: habilidad fundamental en todos los extremos, tanto para atacar como para defender. 25

28 Defensa: nos aporta la contención del equipo junto al portero, es indispensable tener un nivel de defensa bueno para poder parar a los delanteros rivales. Anotación: esencial para poder culminar las ocasiones de gol, es indispensable para los delanteros. Balón parado: habilidad que marca la capacidad para lanzar todo tipo de faltas, penaltis, corner,. Además de estas habilidades, un jugador puede estar lesionado, con lo que no se puede alinear, o bien estar amonestado por haber recibido tarjeta roja o doble tarjeta amarilla en el anterior partido oficial con lo que deberá cumplir un partido de sanción y tampoco se podrá alinear. A partir de todas estas características y habilidades de los jugadores, cualquiera que tenga un equipo en hattrick debe de clasificar a sus jugadores y realizar jornada a jornada la mejor alineación posible para intentar ganar cada partido. Por lo que todos estos datos no hacen sino avalar la utilidad de un sistema experto que nos ayude; primero a clasificar a nuestros jugadores indicándonos en que posición nos darán más rendimiento, y después realizar la mejor alineación posible con los jugadores disponibles. 26

29 3. Definición y desarrollo del Sistema Experto 27

30 3.1. Análisis de viabilidad Una vez se tiene definido el problema, debemos determinar si dicho problema es susceptible, o no, de ser tratado con la tecnología de los sistemas expertos. Esto se conoce como estudio de viabilidad de la aplicación y se lleva a cabo realizando una evaluación de la tarea desde la perspectiva de la ingeniería del conocimiento, para luego cuantificar dicha evaluación para ver el grado de dificultad que presenta la tarea. 28

31 Características de Plausibilidad Existen personas expertas en el juego de hattrick, es decir, llevan varios años participando en el juego con resultados satisfactorios, y los expertos colaboradores en este proyecto lo son, así mismo cooperan de buen grado y están involucrados en la realización del sistema, ya que ellos mismos podrán beneficiarse del mismo. Para este sistema experto, el grupo de expertos está formado por 4 personas: Javier Cruzado Toro (jugador de hattrick desde hace 3 años), Daniel Cruzado Toro (jugador de hattrick desde hace 2 años), Diego Ranea Santamaría (jugador de hattrick desde hace 3 años), Alfredo Gil Mira (jugador de hattrick desde hace 3 años). La realización de la mejor alineación posible para el conjunto de jugadores de un equipo es una tarea comprensible y que no requiere ningún tipo de pericia física, los resultados deben de ser satisfactorios ya que la realización correcta de la alineación cada jornada va a marcar la competitividad del equipo y su posible ascenso a divisiones superiores. Además existen abundantes equipos para probar el correcto funcionamiento del sistema. 29

32 CAT. IDEN. CAT. PESO (P) DENOMINACIÓN DE LA CARACTERÍSTICA TIPO VALOR (V) EX P1 10 Existen expertos E 10 EX P2 10 El experto asignado es genuino E 7 EX P3 8 El experto es cooperativo D 10 EX P4 7 El experto es capaz de articular D 9 sus métodos pero no categoriza TA P5 10 Existen suficientes casos de E 10 prueba TA P6 10 La tarea está bien estructurada y D 9 se entiende TA P7 10 Sólo requiere habilidad D 8 cognoscitiva TA P8 9 No se precisan resultados D 7 verdaderamente comprometidos TA P9 9 La tarea no requiere mucho D 7 sentido común DU P10 7 Los directivos están D 10 verdaderamente comprometidos en el proyecto 30

33 Características de Justificación Como ya hemos mencionado anteriormente la realización de la mejor alineación con los jugadores disponibles en un equipo puede ser una labor tediosa y al intervenir distintas variables puede ser complicada. Tener una herramienta que nos consiga de una manera rápida y fiable la alineación ideal evitaría tener que realizar esta tarea tediosa y mejorará los resultados de nuestro equipo en las competiciones, además de poder tener en cuenta de una forma directa y rápida la incorporación de nuevos jugadores a nuestro equipo, así como la mejora en las habilidades de los mismos. CAT. IDEN. CAT. PESO (P) DENOMINACIÓN DE LA CARACTERÍSTICA TIPO VALOR (V) EX J1 10 El experto no está disponible E 6 EX J2 10 Hay escasez de experiencia D 9 humana TA J3 8 Existe necesidad de experiencia D 10 simultánea en muchos lugares TA J4 10 Necesidad de experiencia en E 7 entornos hostiles, penosos o poco gratificantes TA J5 8 No existen soluciones alternativas E 5 admisibles DU J6 7 Esperan una alta tasa de D 5 recuperación de la inversión DU J7 8 Resuelve una tarea útil y E 10 necesaria 31

34 Características de Adecuación Un sistema experto, además de ser posible y útil en determinadas circunstancias, debe ser adecuado. Para ello el problema en cuestión debe tener ciertas cualidades intrínsecas. En este caso, la realización de la mejor alineación posible tiene un gran valor práctico y tiene la complejidad suficiente como para que un experto humano necesite abundante experiencia para poder realizarlo y está lo suficientemente acotado para que sea manejable y lo bastante amplio como para que tenga interés práctico. 32

35 CAT. IDEN. CAT. PESO (P) DENOMINACIÓN DE LA CARACTERÍSTICA TIPO VALOR (V) EX A1 5 La experiencia del experto está D 8 poco organizada TA A2 6 Tiene valor práctico D 10 TA A3 7 Es más táctica que estratégica D 9 TA A4 7 Sirve a necesidades a largo plazo E 10 TA A5 5 La tarea, que no es demasiado D 9 fácil, pero es de conocimiento intensivo, tanto propio del dominio, como de manipulación de la información TA A6 6 Es de tamaño manejable, y, o es D 10 posible un enfoque gradual y, o, una descomposición en subtareas independientes EX A7 7 La transferencia de experiencia E 10 entre humanos es factible TA A8 6 Estaba identificada como un D 6 problema en el área y los efectos de la introducción de un SE pueden planificarse TA A9 9 No requiere respuestas en tiempo E 10 real inmediato TA A10 9 La tarea no requiere investigación E 5 básica y usa, sí alguna, poca generación y entendimiento de lenguaje natural TA A11 5 El experto usa básicamente D 6 razonamiento simbólico que implica factores subjetivos TA A12 5 Es básico de tipo heurístico D 8 33

36 Características de Éxito. Además de las consideraciones puramente técnicas para la aplicación de un sistema experto en la solución de un problema, existen otras cuestiones que, de no tenerlas en cuenta, pueden dar al traste con el proyecto. 34

37 CAT. IDEN. CAT. PESO (P) DENOMINACIÓN DE LA CARACTERÍSTICA TIPO VALOR (V) EX E1 8 No se sienten amenazados por el proyecto son capaces de sentirse intelectualmente unidos al proyecto EX E2 6 Tienen un brillante historial en la realización de esta tarea EX E3 5 Hay acuerdos sobre lo que constituye una buena solución EX E4 5 La única justificación para dar un paso en la solución es la claridad de la solución final EX E5 6 No hay un plazo de finalización estricto, ni ningún otro proyecto depende de esta tarea TA E6 7 No está influenciad por vaivenes políticos TA E7 8 Existen ya sistemas expertos que resuelven esa o parecida tarea TA E8 8 Hay cambios mínimos en los procedimientos habituales TA E9 5 Las soluciones son explicables o interactivas TA E10 7 La tarea es de I+D de carácter práctico, pero no ambas cosas simultáneamente TA E11 6 Están mentalizados y tiene expectativas realistas tanto en el alcance como en las limitaciones DU E12 7 No rechazan de plano esta tecnología DU E13 6 El sistema interactúa inteligentemente y amistosamente con el usuario DU E14 9 El sistema es capaz de explicar al usuario su razonamiento DU E15 8 La inserción del sistema se efectúa sin traumas DU E16 6 Están comprometidos durante toda la duración del proyecto, incluso después de su implantación DU E17 8 Se efectúa una adecuada transferencia tecnológica D 10 D 7 D 10 D 10 D 6 E 10 D 9 D 10 D 10 E 9 D 10 E 10 D 10 D 10 D 10 D 10 E 10 35

38 El resultado del Test es el siguiente: MEDIA Posibilidad Justificación Adecuación Éxito TOTAL Y como el umbral fijado estaba en 7.5 el resultado del test nos demuestra la viabilidad del proyecto, ya que se convierte en

39 3.2. Adquisición del conocimiento La adquisición del conocimiento, es con total seguridad el punto más costoso de los que componen el desarrollo de un sistema experto. Se trata de un proceso de una larga y continua interacción con los expertos para obtener el conocimiento, en nuestro caso, los criterios para poder clasificar a los jugadores de un equipo y realizar la mejor alineación posible de forma que pueda ser implementado en un programa. Como hemos dicho, la adquisición del conocimiento, no es un procedimiento sencillo, sino más bien se podría considerar como una labor de artesanía, ya que no existe ningún método automático y en cada caso tenemos que adaptarnos a las características particulares del problema y a los expertos. Como es lógico la adquisición del conocimiento está supeditada al experto que es el poseedor de los conocimientos a adquirir, esto da lugar a posibles inconvenientes, como: dificultad de disponer del tiempo del experto, posibles sesgos, ya que todo experto tiene su propia visión del dominio y de los problemas que le conciernen, limitación a una sola línea de razonamiento, o incompletitudes de la experiencia del dominio. La mayoría de estos inconvenientes se ven paliados por la presencia de un grupo de expertos en lugar de una solo, ya que de este modo, aseguramos la completitud de la base de conocimientos, mejoramos la verosimilitud de obtener conocimientos especializados, se incrementa la calidad acerca de los conocimientos adquiridos debido al consenso del grupo de expertos. 37

40 Naturalmente el uso de un grupo de expertos para la educción del conocimiento, también conlleva una serie de inconvenientes, que se traducen en una mayor complejidad del proceso de adquisición. Ya que hay que fusionar las distintas estructuras de conocimiento individuales de los distintos expertos en una única estructura que los englobe. Todo este proceso de obtención del conocimiento se ha realizado utilizando el método más usual en la elaboración de adquisición que son las entrevistas. La entrevista consiste en una interacción sistemática del ingeniero del conocimiento con el experto para extraer los conocimientos de la experiencia de éste. Al conversar con el experto, se revelan sus objetivos cuando resuelve problemas, cómo están relacionados u organizados sus pensamientos, y los procesos a través de los cuales resuelve el problema. Además las entrevistas también pueden utilizarse para conocer la opinión de usuarios o directivos. Este método de educción puede estructurarse en varios grados y distintas maneras, que van desde la falta total de estructuración hasta la estructuración estricta. Desde la tormenta de ideas hasta el análisis de casos concretos. El papel del ingeniero del conocimiento consiste en una cuidadosa preparación de entrevistas con vistas tanto a recoger el conocimiento, como a conseguir que el experto se involucre. También debe ser capaz de una hábil y prudente conducción de las entrevistas pasando de lo general a lo concreto. Por último debe conceptuar y modelar el conocimiento que se extrae de las entrevistas. 38

41 A continuación, se describe todo el proceso de adquisición del conocimiento realizado en este proyecto. El procedimiento ha constado de las siguientes etapas: identificación del dominio de conocimiento conceptualización del dominio de conocimiento formalización y codificación del conocimiento chequeo y validación Para ello, la herramienta utilizada ha sido como ya hemos mencionado la entrevista con el experto. Dichas entrevistas, nunca han sido en grupo, si no que se han realizado a todos los expertos individualmente. Se han realizado las mismas entrevistas a todos los expertos, con puntuales excepciones ya que en algún caso se hizo necesaria alguna entrevista puntual para aclarar o resolver alguna ambigüedad o equívoco concreto referente a la visión particular de un experto. Pero en general el proceso ha sido el mismo para todos y cada una de los expertos. En principio se preparaba una entrevista y se realizaba a los expertos. Una vez analizados los datos de cada una de ellas, se ponían en común y se sacaban conclusiones. Con esto, se preparaba la siguiente entrevista que, en primer lugar mostraba los resultados obtenidos en el proceso anterior para validarlos y para resolver conflictos. Y en segundo lugar y una vez validado lo anterior se profundiza en el dominio de conocimientos. Conforme se iban dando pasadas a este bucle, las entrevistas eran más y más estructuradas enfocadas a partes concretas del dominio. 39

42 Para mejor compresión de todo este proceso y para evitar reproducir en su totalidad las entrevistas ya que en muchos casos son bastante similares, seguidamente se resume el proceso de adquisición del conocimiento, incluyendo ejemplos de las entrevistas. La primera entrevista que se realizó, tenía una doble finalidad. En primer lugar determinar los requisitos o necesidades de los usuarios del sistema experto, ya que los mismos expertos, jugadores de hattrick, van a ser usuarios del mismo. No se pretendía realizar una especificación formal de requisitos, simplemente conocer la visión de los posibles usuarios. Las principales conclusiones fueron que el sistema debía tener una interfaz amigable y sencilla, ya que lógicamente los potenciales usuarios no poseen conocimientos de informática. Y que sería ideal que fuese en formato Web. La otra finalidad consistía en la identificación del dominio del problema, es decir se pretendía identificar el alcance de la aplicación del sistema basado en conocimiento así como la gama de problemas que pueden ser resueltos por él y para ello se utilizó una entrevista abierta en la que se plantean preguntas al experto de manera espontánea o de tanteo del dominio. De la que se pudo sacar las siguientes conclusiones: 40

43 P: Cómo eliges a los jugadores para realizar la alineación de un partido en hattrick? R: En primer lugar, pienso con que táctica quiero jugar, 4-4-2, 3-5-2, etc.., una vez que tengo claro cual es la formación que voy a utilizar, analizo los jugadores para saber cual es su puesto ideal, para después colocar a los mejores en cada puesto. P: Me podrías indicar entonces, que formaciones son las posibles? R: Pues existen varias formaciones principales, que son: Pero dentro de estas formaciones, se pueden seleccionar varios variantes, como puede ser, en el caso de tener más de un delantero, elegir que todos sean delanteros centros o bien que haya alguno que sea más media punta. Y en la defensa cuando no tienes a 4 para cubrir los dos puestos de lateral y los dos puestos de central, elegir jugar con tres centrales, o bien jugar con dos centrales y un lateral, etc. 41

44 P: A grosso modo, qué demarcaciones posibles para un jugador crees que existen en hattrick? R: Pues existen varias demarcaciones posibles, básicamente son: Portero Defensa Central Defensa lateral Medio Centro Extremo Delantero Centro Media Punta P: Entonces, el clasificar a los jugadores en las mejores demarcaciones, te ayuda en algo más que para realizar la alineación de un partido de liga? R: Pues la verdad es que sí, ya que en primer lugar me hace ver en que demarcaciones puede tener más carencia de jugadores mi equipo, lo que me permite seleccionar mejor los fichajes a realizar. Y en segundo lugar, una cosa son los partidos de liga y otra los partidos amistosos, ya que para los partidos amistosos no se debe de poner a los titulares, ya que un exceso de partidos puede provocar lesiones y además, si siempre juegan los mismos no se consigue que la habilidad que se esté entrenando cada semana mejore en los jugadores que no juegan nunca. 42

45 P: Qué ocurre si no tienes suficientes jugadores para cubrir, por ejemplo, el centro del campo? R: Es algo que puede ocurrir debido a las lesiones y las sanciones, en este caso lo que intento es cubrir los puestos con los jugadores que sin ser especialistas en esa posición puedan hacerlo mejor. P: En este sentido, crees que existe alguna demarcación especial de la que crees que si un jugador pertenece a esa demarcación no puede pertenecer a otra? R: Claramente sí, el potero no puede actuar como nada más en hattrick, ya que el juego está montado de esta manera. El juego te permite promocionar cada semana a un jugador de la cantera para que forme parte de tu equipo, y en este punto el juego te pide que selecciones que tipo de jugador quieres promocionar, un portero o un jugador de campo. Un portero sólo va a tener puntuación en la habilidad portería, y un jugador de campo no va a tener puntuación en la habilidad portería. Como mucho un portero podrá tener puntuación en liderazgo para ser el capitán de un equipo o en balón parado para lanzar las faltas, penaltis y corners. 43

46 En base a estas entrevistas realizadas, nos permitió acotar un poco más el problema y obtener algunos requisitos que no se habían tenido en cuenta en un principio. Al comienzo del sistema experto, se pensó que en base a unos jugadores de un equipo, directamente se sacase la mejor alineación posible una vez se hubiese marcado la formación deseada. Pero al realizar estas entrevistas me di cuenta que sería muy conveniente y beneficiosa para el sistema experto y para el futuro usuario, que el sistema realizase una fase previa de clasificación de los jugadores. Ya que en base al mismo se puede presentar al usuario a sus jugadores con sus demarcaciones ideales, lo que le puede ayudar al usuario final a realizar alineaciones para partidos amistosos para no desgastar a los jugadores de campo, y además provocar que se entrene el resto del equipo con los partidos amistosos. Así que parecía claro que el sistema debía realizar en primer lugar una fase de clasificar a los jugadores por demarcaciones. Pero no sólo dar a demarcación ideal para ese jugador, sino que también obtener el valor de ese jugador para el resto de demarcaciones y poder presentar al usuario al menos las dos mejores demarcaciones para ese jugador. Esto se deberá cumplir para todos los jugadores excepto para los porteros ya que como se puede leer en la entrevista el portero no puede actuar como jugador de campo. Con esta primera aproximación se ha conseguido acotar un poco más el problema, además de conseguir especificar un poco más los requisitos, que son: 44

47 El sistema deberá clasificar a los jugadores por demarcaciones El sistema debe permitir seleccionar la formación. El sistema obtendrá la mejor alineación posible en base a los jugadores y la formación elegida. Una vez obtenida esta información, disponíamos de elementos suficientes para pasar a la siguiente fase de la adquisición del conocimiento. La conceptualización del dominio del conocimiento, es probablemente la etapa más importante, en ella el ingeniero del conocimiento ha de colaborar intensamente con los expertos para recoger y organizar el conocimiento. El conocimiento del experto ha de ser formalizado usando conceptos y relaciones, eliminando casuísticas particulares o anécdotas. Se ha de conseguir un conocimiento organizado, coherente, inequívoco y no redundante. Para ello, se realizaron a los expertos una serie de entrevistas semiestructuradas en principio y estructuradas al final, con la intención de conocer con detalle, en primer lugar, las características que denotan la demarcación de cada jugador, y en segundo lugar, que hace seleccionar a un jugador para que entre a formar parte de la alineación ideal. Así en, en primer lugar, se buscó averiguar si se usan las mismas habilidades para clasificar a los jugadores por demarcación y para seleccionar la alineación ideal, para concretar en cada demarcación. Los resultados de este proceso fueron: 45

48 P: Se usan las mismas habilidades para clasificar a los jugadores por demarcaciones y realizar la alineación ideal? R: No exactamente, ya que a la hora de clasificar a un jugador por demarcación, no se tiene en cuenta si está lesionado o no, si está sancionado o no, y tampoco se tiene en cuenta la forma, ya que esta sólo influye para la alineación. Con estos resultados, se buscaron las definiciones de cada demarcación, para saber que hace que un jugador pertenezca a una demarcación y no a otra, para después poder obtener los criterios para la alineación. Los resultados de este proceso fueron: P: Qué define que un jugador sea portero y no jugador de campo? R: Este es el caso más simple, ya que un portero es aquel que tiene en la habilidad portería mayor o igual que insuficiente, ya que tal y como está estructurado el juego un jugador de campo, nunca va a tener en la habilidad portería más de desastroso. P: Qué define que un jugador sea defensa central? R: La habilidad más importante de un defensa central es lógicamente la defensa, aunque en menor medida en un defensa central también se debe tener en cuenta los pases, ya que nos permiten sacar el balón jugado y también es 46

49 importante aunque en mucha menor medida la experiencia. El valor del resto de habilidades es intrascendente para un defensa central. P: Qué define que un jugador sea defensa lateral? R: En este caso, es importante también el valor de la habilidad defensa, pero a diferencia del defensa central también es importante el valor de la habilidad lateral, y por último pero en menor medida el valor de la experiencia es algo a tener en cuenta. P: Qué define que un jugador sea Medio Centro? R: Para ser medio centro, un jugador debe tener bastante valor principalmente en dos habilidades, condición y jugadas, quizá un poco más en jugadas, ya que es la habilidad que va a permitir a un jugador no perder la pelota, algo muy importante en el centro del campo, aunque es necesario que tenga suficiente valor en condición, ya que si no va a provocar que se canse en seguida. Por otro lado, para ser medio centro, también se deben tener en cuenta en cierto grado las habilidades de pases y defensa. P: Qué define que un jugador se Extremo? R: La habilidad más importante a tener en cuenta para un extremo es el valor de la habilidad lateral, ya que éste jugador va a estar permanentemente en la 47

50 banda. Sin embargo, también se tiene que tener en cuenta las habilidades de jugadas y condición, y en menor medida los pases. P: Qué define que un jugador sea Media Punta? R: Para que un jugador sea media punta, es necesario que tenga suficiente valor la habilidad de anotación, siendo está muy importante para esta demarcación, además se debe tener en cuenta el valor de las habilidades de jugadas y condición, y en menor medida el valor de la habilidad de pases. P: Qué define que un jugador sea delantero centro? R: La primordial característica de un delantero centro, incluso en mayor medida que en el media punta, es que el valor de la anotación sea claramente superior al resto de habilidades, por otro lado, aunque en mucho menor medida es conveniente que tenga algo de valor la habilidad de pases, y algo de experiencia. Una vez obtenidos los resultados para la clasificación de los jugadores por demarcaciones, se pasa a realizar una serie de entrevistas para poder analizar las posibles formaciones que el sistema debe conocer. 48

51 P: Qué jugadores son necesarios para obtener una alineación ideal con la formación 4-4-2? R: Para la defensa, será necesario obtener a los dos mejores defensores centrales y los dos mejores defensores laterales, para el centro del campo deberemos elegir entre jugar con dos medio centros y dos extremos o bien con un extremos y tres medio centros, en cualquier caso será necesario obtener a los mejores jugadores para cada posición. Además para la delantera, es necesario primero decidir si se quiere jugar con dos delanteros centros o bien con un delantero centro y un media punta. Si se decide por dos delanteros centros, será necesario obtener los dos mejores delanteros centros, en cambio si se jugar con un delantero centro y un media punta, será necesario obtener el mejor jugador en cada puesto. P: Qué jugadores son necesarios para obtener una alineación ideal con la formación 3-5-2? R: Para el centro del campo, será necesario elegir entre tres medio centros y dos extremos o cuatro medio centros en ambos casos se deberá elegir a los mejores jugadores en cada posición. Sin embargo, para la defensa, se tiene que saber primero si se quiere jugar con tres centrales, o bien si se quiere jugar con dos centrales y un lateral, se descarta la opción de dos laterales y un central, ya que la experiencia en el juego demuestra que no es una formación óptima; en cualquier caso se deben elegir los mejores para cada posición. Además para la 49

52 delantera, tenemos que averiguar igual que en el caso anterior si se pretende jugar con dos delanteros centros, o bien con un delantero centro y un media punta, y de la misma forma se deben obtener los mejores en cada posición. P: Qué jugadores son necesarios para obtener una alineación ideal con la formación 5-3-2? R: En este caso, en defensa necesitaremos a los mejores tres defensores centrales, y a los dos mejores defensores laterales. En el centro del campo, podemos elegir jugar con un extremo y dos medio centros, o bien con tres medio centros, es necesario descartar la opción de jugar con un medio centro y dos extremos ya que no es una alineación nada óptima para el juego de hattrick, donde el centro del campo es fundamental. Por último, en el caso de la delantera es necesario saber si se quiere jugar, al igual que en las anteriores formaciones, con dos delanteros centros o bien con un delantero centro y un media punta, en cualquier caso es necesario obtener a los mejores jugadores en cada puesto. P: Qué jugadores son necesarios para obtener una alineación ideal con la formación 4-5-1? R: En este caso, para la defensa deberemos seleccionar a los dos mejores defensores centrales, y a los dos mejores defensores laterales. Para el centro del campo, se deberá elegir entre jugar con dos extremos y tres medio centros o bien cuatro medio centros y un extremo, en cualquier caso es necesario elegir a 50

53 los mejores jugadores en cada puesto; y por último, para la delantera, se deberá elegir al mejor delantero centro. No se debe contemplar la posibilidad de jugar con sólo con un media punta, ya es necesario jugar al menos con un delantero centro. P: Qué jugadores son necesarios para obtener una alineación ideal con la formación 5-4-1? R: Para completar esta formación en defensa, se debe elegir a los tres mejores defensores centrales y los dos mejores defensores laterales. En el centro del campo, se debe decidir entre jugar con dos medio centros y dos extremos o bien tres medio centros y un extremo. Y para la delantera, se debe seleccionar al mejor delantero centro, ya que como he mencionado es necesario jugar con al menos un delantero centro. P: Qué jugadores son necesarios para obtener una alineación ideal con la formación 4-3-3? R: Para completar esta formación en defensa, necesitaremos a los dos mejores defensores centrales y a los dos mejores defensores laterales. En el centro del campo, deberemos elegir si queremos jugar con dos medio centros y un extremo, o bien con tres medio centros, y en cualquier caso seleccionar a los mejores. Por último en la delantera tenemos tres opciones, jugar con un delantero centro y dos media puntas, con dos delanteros centros y un media punta, o bien con tres delanteros centros. 51

54 P: Qué jugadores son necesarios para obtener una alineación ideal con la formación 3-4-3? R: En este caso, para la defensa deberemos elegir entre jugar con dos defensores centrales y un lateral, o bien con tres defensores centrales. En el centro del campo debemos elegir entre jugar con dos extremos y dos medio centros o bien con tres medio centros y un extremo; y en el caso de la delantera será necesario elegir entre jugar con un delantero centro y dos media puntas, con dos delanteros centros y un media punta, o bien con tres delanteros centros. En cualquier caso es necesario seleccionar a los mejores para cada posición. Así, con estas entrevistas hemos podido descubrir las distintas opciones de formación y en cada una de ellas, que jugadores debemos seleccionar para completarlos. De una forma esquemática, el conocimiento obtenido de estas entrevistas es el siguiente: Figura 1. Variantes de una formación

55 Figura 2. Variantes de una formación Figura 3. Variantes de una formación

56 Figura 4. Variantes de una formación Figura 5. Variantes de una formación

57 Figura 6. Variantes de una formación Figura 7. Variantes de una formación

58 En base a todas estas posibilidades de formaciones, se realizaron una nueva ronda de entrevistas estructuradas para averiguar si todas las formaciones posibles eran o no recomendadas para el juego, lo que dio como resultado las formaciones reales que se pueden elegir para realizar una alineación y que nos den un resultado óptimo en el juego. El resultado de estas entrevistas fue el siguiente: 4-4-2: o Normal: 2 Defensas Centrales 2 Defensas Laterales 2 Medio Centros 2 Extremos 2 Delanteros Centro o Con Media Punta: 2 Defensas Centrales 2 Defensas Laterales 2 Medio Centros 2 Extremos 1 Media Punta 1 Delantero Centro o Con tres medio centros: 2 Defensas Centrales 2 Defensas Laterales 3 Medio Centros 1 Extremo 2 Delanteros Centro o Con media punta y tres medio centros: 2 Defensas Centrales 2 Defensas Laterales 3 Medio Centros 1 Extremo 1 Media Punta 1 Delantero Centro 56

59 3-5-2: o Normal: 3 Defensas Centrales 3 Medio Centros 2 Extremos 2 Delanteros Centro o Con defensa lateral: 2 Defensas Centrales 1 Defensa Lateral 3 Medio Centros 2 Extremos 2 Delanteros Centro o Con cuatro medio centros: 3 Defensas Centrales 4 Medio Centros 1 Extremo 2 Delanteros Centro o Con cuatro medio centros y un defensa lateral: 2 Defensas Centrales 1 Defensa Lateral 4 Medio Centros 1 Extremo 2 Delanteros Centro o Con un media punta: 3 Defensas Centrales 3 Medio Centros 2 Extremos 1 Delantero Centro 1 Media Punta o Con un defensa lateral y un media punta: 2 Defensas Centrales 1 Defensa Lateral 3 Medio Centros 2 Extremos 57

60 1 Delantero Centro 1 Media Punta o Con cuatro medio centros y un media punta: 3 Defensas Centrales 4 Medio Centros 1 Extremo 1 Delantero Centro 1 Media Punta o Con un defensa lateral, cuatro medio centros y un media punta: 2 Defensas Centrales 1 Defensa Lateral 4 Medio Centros 1 Extremo 1 Delantero Centro -1 Media Punta 5-3-2: o Normal: 3 Defensas Centrales 2 Defensas Laterales 3 Medio Centros 2 Delanteros Centro o Con un extremo: 3 Defensas Centrales 2 Defensas Laterales 2 Medio Centros 1 Extremo 2 Delanteros Centro o Con un media punta: 3 Defensas Centrales 2 Defensas Laterales 3 Medio Centros 1 Delantero Centro 1 Media Punta o Con un extremo y un media punta: 3 Defensas Centrales 2 Defensas Laterales 58

61 2 Medio Centros 1 Extremo 1 Delantero centro 1 Media Punta 4-5-1: o Normal: 2 Defensas Centrales 2 Defensas Laterales 3 Medio Centros 2 Extremos 1 Delantero Centro o Con cuatro medio centros: 2 Defensas Centrales 2 Defensas Laterales 4 Medio Centros 1 Extremo 1 Delantero Centro 5-4-1: o Normal: 3 Defensas Centrales 2 Defensas Laterales 2 Medio Centros 2 Extremos 1 Delantero Centro o Con tres medio centros: 3 Defensas Centrales 2 Defensas Laterales 3 Medio Centros 1 Extremo 1 Delantero Centro 4-3-3: o Normal: 59

62 2 Defensas Centrales 2 Defensas Laterales 3 Medio Centros 3 Delanteros Centro o Con un extremo: 2 Defensas Centrales 2 Defensas Laterales 2 Medio Centros 1 Extremo 3 Delanteros Centro o Con un media punta: 2 Defensas Centrales 2 Defensas Laterales 3 Medio Centros 2 Delanteros Centro 1 Media Punta o Con dos media puntas: 2 Defensas Centrales 2 Defensas Laterales 3 Medio Centros 1 Delantero Centro 2 Media Puntas o Con un extremo y un media punta: 2 Defensas Centrales 2 Defensas Laterales 2 Medio Centros 1 Extremo 2 Delanteros Centro 1 Media Punta o Con un extremo y dos media puntas: 2 Defensas Centrales 2 Defensas Laterales 2 Medio Centros 1 Extremo 1 Delantero Centro 2 Media Puntas 60

63 3-4-3: o Normal: 3 Defensas Centrales 2 Medio Centros 2 Extremos 3 Delanteros Centro o Con tres medio centros: 3 Defensas Centrales 3 Medio Centros 1 Extremo 3 Delanteros Centro o Con tres medio centros y un defensa lateral 2 Defensas Centrales 1 Defensa Lateral 3 Medio Centros 1 Extremo 3 Delanteros Centro o Con tres medio centros, un defensa lateral y un media punta: 2 Defensas Centrales 1 Defensa Lateral 3 Medio Centros 1 Extremo 2 Delanteros Centro 1 Media Punta o Con tres medio centros, un defensa lateral y dos media puntas: 2 Defensas Centrales 1 Defensa Lateral 3 Medio Centros 1 Extremo 1 Delantero Centro 2 Media Puntas o Con un media punta: 3 Defensas Centrales 2 Medio Centros 2 Extremos 61

64 2 Delanteros Centro 1 Media Punta o Con dos media puntas: 3 Defensas Centrales 2 Medio Centros 2 Extremos 1 Delantero Centro 2 Media Puntas o Con tres medio centros y un media punta: 3 Defensas Centrales 3 Medio Centros 1 Extremo 2 Delanteros Centro 1 Media Punta o Con tres medio centros y dos media puntas: 3 Defensas Centrales 3 Medio Centros 1 Extremo 1 Delantero Centro 2 Media Puntas Por último, falta realizar una ronda de entrevistas para poder averiguar de entre todos los jugadores que tenemos como, por ejemplo, delanteros centro, como elegimos el o los que van a formar parte de la alineación. Para ello, se realizó una nueva ronda de entrevistas en la que se pretendía adquirir el conocimiento necesario. Los resultados de este proceso fueron: P: Qué características hay que mirar primero a la hora de elegir a los jugadores para realizar una alineación? 62

65 R: En primer lugar, hay que descartar a todos los jugadores que estén lesionados o sancionados, ya que no podrán jugar y si se introducen en la alineación hattrick lo detectará y dejará el lugar que ocupan en el campo vacío. P: Una vez descartados a los sancionados y/o lesionados, cómo se debe proceder para realizar la alineación? R: Pues una vez descartados los lesionados y/o sancionados, y una vez elegida la formación que se va a utilizar, se debe poner a los mejores en cada puesto, para ello, se debe de volver a clasificar a los jugadores, pero ahora se debe de tener en cuenta la forma y la experiencia de cada uno de ellos, ya que para la alineación estas características influyen. Porque podemos tener, por ejemplo, un delantero centro buenísimo, y otro no tan bueno, pero el buenísimo tiene muy baja forma, y el menos bueno, tiene una forma buenísima, pues bien, el que es menos bueno al tener una forma buenísima rendirá más que el que es buenísimo. Además, al realizar la alineación, es necesario poner en cada posición a un especialista para esa demarcación y sólo en el caso de no tener un especialista, se debe buscar a los que tengan como segunda especialidad esa posición el que mejor sea. Ya que si colocamos a jugadores no especialistas, con forme vayan jugando partidos pueden ir perdiendo cualidades en su especialidad. P: Por tanto, En que grado deben de afectar la forma y la experiencia en la alineación? 63

66 R: Pues para cada posición, la combinación de la forma y la experiencia, se debe de considerar un factor más que se debe incrementar al resto de habilidades. Es decir, la combinación de la forma y la experiencia debe multiplicar las características de un jugador. La forma debe de ser un poco más importante que la experiencia. 64

67 3.3. Representación del conocimiento Una vez finalizado el proceso de adquisición del conocimiento, hay que seleccionar el método de representación del conocimiento que mejor se adapte a las necesidades de nuestro sistema, esta decisión es similar a la de elegir el lenguaje de programación más apropiado para un determinado problema. A la hora de elegir el método de representación debemos elegir a priori, el esquema que mejor permita expresar de manera natural, fiel y completa los conocimientos. Pero además hay que tener en cuenta otros factores como: los conocimientos del ingeniero del conocimiento o el soporte de programación. Para este proyecto, he elegido como método de representación del conocimiento un esquema de representación estructurada, en concreto, los marcos, ya que al considerar las distintas alternativas me di cuenta que era el que mejor se adaptaba, debido a que cada posición de un jugador seria un marco. Además ofrecen una gran facilidad para la creación y modificación de la base de conocimiento, por lo que simplificaría las posibles ampliaciones del sistema. Los marcos nos ayudan a representar objetos y situaciones típicas. El sistema de marcos intenta integrar nociones declarativas sobre los objetos y eventos con nociones procedurales sobre como recuperar información o alcanzar metas. Así los marcos se forman con estructuras de datos complejas, y cada marco puede ser pensado como slots (casilleros) cada slot corresponde a un atributo de un objeto. 65

68 Así en este caso concreto, como se ha podido ver en la fase de adquisición del conocimiento, vamos a necesitar dos conjuntos de marcos distintos. El primero para que con cada jugador de un equipo podamos clasificarlo en función de sus habilidades, en que demarcación en el campo rinde más. Pero no sólo deberemos tener en cuenta su demarcación ideal, sino que deberemos poder tener por orden todas las demarcaciones, empezando por la ideal, donde es mejor ese jugador, y terminando por la posición donde menos rendimiento nos va a dar, ya que el objetivo es que podamos realizar la mejor alineación con los jugadores disponibles, pero deberemos abarcar todas las demarcaciones del campo. El segundo conjunto de marcos, es el que nos va a marcar que jugadores se van a alinear en nuestro equipo, ya que para conseguir la alineación ideal necesitamos tener en cuenta las características de forma, si está lesionado, si tiene que cumplir un partido de sanción, que no se tienen en cuenta a la hora de clasificar a los jugadores por demarcación. Nos basaremos en los resultados que nos ha aportado la clasificación de jugadores para poder realizar la mejor alineación. Para ambos casos, de la fase de la adquisición del conocimiento se ha podido abstraer las 7 posiciones en el campo en los que se puede clasificar a un jugador, estas son: o Portero o Defensa Central o Defensa Lateral o Medio Centro o Extremo 66

69 o Media Punta o Delantero Centro Antes de pasar a detallar los dos conjuntos de marcos, es necesario, en base a los valores que pueden tomar las habilidades de un jugador, asignarles un valor numérico para poder simplificar la representación del conocimiento. Por tanto tendremos para las habilidades la siguiente tabla, daremos el valor más pequeño a la peor puntuación posible: Valor Habilidad Valor Numérico No sabe 0 Desastroso 1 Horrible 2 Pobre 3 Débil 4 Insuficiente 5 Aceptable 6 Bueno 7 Excelente 8 Formidable 9 Destacado 10 Brillante 11 Magnífico 12 Clase mundial 13 Sobrenatural 14 Titánico 15 Extraterrestre 16 Mítico 17 Mágico 18 Utópico 19 Divino 20 Figura 8. Mapeo de la habilidad con su valor numérico 67

70 Vamos a pasar a describir en detalle, los dos conjuntos de marcos a que se ha llegado tras la fase de adquisición del conocimiento. En ambos casos, se ha llegado a la conclusión que cada marco va a corresponder a cada demarcación en el campo. Los marcos se van a representar de la siguiente manera: Nombre Marco Habilidad 1 Peso 1 Habilidad 2 Peso 2 Habilidad n Peso n Conjunto de marcos para la clasificación de los jugadores en una demarcación Defensa Central Defensa Central Defensa 0.8 Lateral 0.15 Experiencia 0.05 Defensa Lateral Defensa Lateral Defensa 0.7 Lateral 0.25 Experiencia

71 Medio Centro Medio Centro Jugadas 0.5 Condición 0.4 Pases 0.05 Defensa 0.05 Extremo Extremo Lateral 0.6 Jugadas 0.15 Condición 0.15 Defensa 0.1 Media Punta Media Punta Anotación 0.6 Jugadas 0.15 Condición 0.15 Pases 0.1 Delantero Centro Delantero Centro Anotación 0.8 Pases 0.15 Experiencia 0.05 Portero Portero Portería >=5 69

72 Conjunto de marcos para la clasificación de los jugadores para la alineación En primer lugar, el primer marco, nos indica si va a entrar en la alineación o no: Jugador Alineable Jugador Alineable Lesionado NO Sancionado NO En segundo lugar, el siguiente marco también se va a aplicar a todos los demás marcos, ya que es el marco de la forma y la experiencia: Forma y Experiencia Forma y Experiencia Forma 0.67 Experiencia 0.43 Por último tenemos los marcos de cada posición, pero que tienen dos slots que se corresponden con los dos marcos anteriores. Portero Portero Alineable SI Forma y Experiencia * Portería 1 70

73 Defensa Central Defensa Central Alineable SI Forma y Experiencia * Defensa 1 Defensa Lateral Defensa Lateral Alineable SI Forma y Experiencia * Defensa 0.75 Lateral 0.25 Medio Centro Medio Centro Alineable SI Forma y Experiencia * Jugadas 0.6 Condición 0.15 Pases 0.15 Defensa 0.1 Extremo Extremo Alineable SI Forma y Experiencia * Lateral 0.6 Jugadas 0.2 Condición 0.1 Pases

74 Media Punta Media Punta Alineable SI Forma y Experiencia * Anotación 0.64 Jugadas 0.15 Pases 0.21 Delantero Delantero Centro Alineable SI Forma y Experiencia * Anotación 0.79 Pases 0.21 Además, de los jugadores que resulten ser los mejores para una formación determinada, es necesario saber cual es el que tiene que actuar como Capitán del equipo y cual es el encargado de realizar las jugadas a balón parado. Para ello, el capitán será aquel de entre todos los que componen la alineación el que mejor valor tenga en la habilidad liderazgo. Y el jugador encargado de realizar las jugadas a balón parado será aquel de entre todos los jugadores que componen la alineación, que mejor valor tenga en la habilidad Balón Parado. 72

75 3.4. Razonamiento (Algoritmo de Alineación Estándar) Una vez explicadas las fases de adquisición y representación del conocimiento, se va a explicar la fase de razonamiento. Es decir como se aplica el conocimiento al problema a tratar. Para ello, lo primero que se hace cuando se va a realizar una alineación de un equipo en base a una formación es aplicar los marcos a todos los jugadores del equipo. Es decir, se calculan los valores de todas las posiciones para cada jugador y se guardan los resultados en la Base de Datos. Por ejemplo: tenemos el jugador Jan Gyring del equipo DeisFinans cuyos valores en sus distintas habilidades son: NOTA: El valor entre paréntesis es el mapeo con el valor numérico. Lesionado: NO Sancionado: NO Forma: bueno (7) Experiencia: formidable (9) Condición: aceptable (6) Portería: desastroso (1) Jugadas: pobre (3) Pases: pobre (3) Lateral: horrible (2) Defensa: excelente (8) Anotación: pobre (3) Balón Parado: horrible (2) 73

76 Aplicando los marcos para la alineación a todas las posiciones se obtienen los siguientes valores para cada posición: Portero: Defensa Lateral: Defensa Central: Medio Centro: Extremo: Media Punta: Delantero Centro: Por tanto, se ve que donde más valor saca este jugador es como Defensa Central, seguido de Defensa Lateral y de Medio Centro. Este proceso se realiza con todos y cada uno de los jugadores del equipo en cuestión. Siempre y cuando cumplan los marcos iniciales de que no estén ni sancionados ni lesionados. En ese caso esos jugadores al no poder tomar parte en el encuentro no serán seleccionados. Y no entrarán en las siguientes fases del algoritmo. Una vez realizado este proceso con todos y cada uno de los jugadores del equipo obtenemos todos los valores por cada posición de cada jugador y podemos comenzar a analizar a todos los jugadores seleccionables para obtener la mejor alineación posible en función de las habilidades de cada jugador en cada momento. 74

77 Para ello, en función de la formación que se elija necesitaremos más o menos jugadores para cada posición en el campo. Para ello el algoritmo siempre intentará seleccionar a los mejores en cada posición, es decir, dentro de aquellos que tengan como su mejor posición la de delantero centro, elegirá al mejor en primer lugar. Pero hay que tener en cuenta que un equipo puede no tener ningún jugador como mejor posición la de delantero centro. Por ello, en primer lugar se intentan sacar el mayor número de jugadores que tengan como mejor posición la que se está buscando, y si no se consigue rellenar una alineación de esta forma, el algoritmo comienza a buscar a los mejores jugadores que tengan como su segunda mejor posición la que se busque, y así sucesivamente. Esto se puede comprender mucho mejor con el análisis de un ejemplo en profundidad: Vamos a suponer que queremos realizar la mejor alineación para una formación estándar, es decir, para completar la alineación necesitamos 1 portero, 2 defensas centrales, 2 defensas laterales, 2 medio centros, 2 extremos y 2 delanteros centro. Para ello el algoritmo en primer lugar y tal y como hemos visto en el ejemplo anterior aplica todos los marcos a todos y cada uno de los jugadores del equipo y obtiene las puntuaciones para cada posición de cada jugador. Comienza y selecciona al mejor portero, es decir, al mejor jugador que tiene la puntuación máxima como portero. Por ejemplo: Jugador 1, que tiene los valores, ordenados de mayor a menor: 75

78 Portero: 39.6 Delantero Centro: 8.86 Extremo: 7.92 Después se seleccionan a los 2 mejores delanteros centro, pero vamos a suponer que sólo tenemos a un jugador que tiene como su mejor posición la de delantero. En este caso el algoritmo en la primera pasada que busca a los mejores jugadores que tienen como mejor posición la de delantero centro seleccionará a este jugador. Pero una vez hecho lo mismo para todas las posiciones verá que todavía le falta un delantero centro para completar la alineación. Para ello, el algoritmo buscará entre todos los jugadores que todavía no han sido elegidos para la alineación, y que tienen como su segunda mejor posición la de delantero centro, el que mayor valor tenga. El algoritmo realiza esta operación para todas y cada una de las posiciones que necesita para completar la alineación. De esta manera se extrae la alineación más compensada posible y mejor posible. El algoritmo también contempla la posibilidad de que no se tengan todos los jugadores necesarios para completar la alineación. Bien porque se trate de un equipo con menos de once jugadores o bien porque aunque en el equipo haya más de once jugadores, al descartar a los lesionados y sancionados, existan menos de once jugadores del equipo disponibles para jugar un partido. En este caso el algoritmo aunque no puede completar 76

79 la alineación muestra a los jugadores disponibles en que posiciones deben jugar, pero avisa que no se dispone de jugadores suficientes para completar la alineación. Por otro lado, el algoritmo una vez obtenida la mejor alineación posible, debe extraer de entre todos los jugadores que componen la alineación aquél que debe ejercer de capitán y aquel que debe ejercer de lanzador a balón parado. Para ello el algoritmo escoge como capitán aquel que tenga mayor valor de la habilidad liderazgo. Y como lanzador de jugadas a balón parado aquél de entre todos los jugadores que componen la alineación, que mayor valor tiene en la habilidad de balón parado. 77

80 4. Descubrimiento de conocimiento a partir de casos históricos (KDD: Knowledge Discovery in Databases) 78

81 4.1. Introducción Una parte esencial para poder realizar el proceso KDD ha sido la elección de los datos como punto de partida del proceso. Para ello me he basado además del conocimiento del problema y las reglas del juego, en una gran cantidad de datos históricos de los distintos partidos jugados por distintos equipos dentro del juego. A continuación se va a desglosar por etapas todo el proceso de KDD llevado a cabo para este proyecto. Explicando en cada etapa mediante ejemplos prácticos como ha sido cada etapa y los resultados que de ella se han ido obteniendo. 79

82 4.2. Aprendizaje del dominio de la aplicación. El conocimiento previo relevante en esta etapa del proceso KDD, consta de: El conocimiento de los expertos en el problema, ya descrito en el proceso de adquisición del conocimiento llevado a cabo a través de entrevistas estructuradas. A este conocimiento de los expertos, se deben sumar los marcos extraídos del proceso de adquisición del conocimiento. Que nos sirven para poder realizar una alineación únicamente teniendo en cuenta las características de los jugadores. Por otro lado es necesario saber que se disponen de datos históricos de todos los partidos jugados de un equipo. Así que se deberá tener en cuenta de alguna manera en el proceso KDD para la realización de la mejor formación posible. En cuanto a los objetivos de la aplicación, el proceso KDD pretende: El sistema deberá clasificar a los jugadores por demarcaciones El sistema debe permitir seleccionar la formación. El sistema obtendrá la mejor alineación posible en base a los jugadores y la formación elegida. Complementar al sistema experto realizado en la primera fase que permitía obtener una alineación para una formación dada, basándose únicamente en las características de los jugadores en un momento determinado. Con esta ampliación, se utilizará el conocimiento extraído por el proceso KDD del histórico de partidos de un equipo de hattrick para eliminar selecciones que pudiera hacer el sistema anterior, o bien modificar las decisiones del mismo que tras el proceso KDD nos indiquen que no son válidas. 80

83 Además, se pretende que una vez obtenido todo este conocimiento el sistema sea capaz de identificar puntos débiles en la plantilla de un equipo y por tanto aconsejar refuerzos en determinadas posiciones para mejorar el nivel global del equipo en sus distintas líneas. 81

84 4.3. Creación de un subconjunto de datos objetivo. En esta etapa del proceso KDD aplicado al ámbito de nuestro sistema, el subconjunto de datos, a partir de ahora tarjeta de datos, está formado por un conjunto de ficheros xml con la información de todos los partidos jugados por un equipo a lo largo de su historia en hattrick. Estos ficheros xml han sido obtenidos apoyándose en herramientas gratuitas que permiten la conexión a los servidores donde reside el juego para extraer la información histórica de un equipo. Se ha intentado implementar esta funcionalidad en este sistema, realizando una solicitud a los creadores del juego, para que se certificase la aplicación como CHPP. Esta certificación es necesaria para que permitan la conexión y extracción de información de sus servidores. Esta petición se realizó hace cerca de un año y tras varios correos electrónicos todavía no se ha recibido respuesta. Es por ello que el sistema se apoya en otras herramientas gratuitas para la extracción de la información histórica de un equipo. La información de cada partido jugado por un equipo viene contenida en cuatro ficheros xml, además de otro fichero xml que ya no está relacionado con ningún partido, sino que contiene los jugadores de los que un equipo dispone con sus características. Aunque más adelante se describirán en detalle, a continuación se muestra un vistazo general de estos ficheros: 82

85 CódigoPartido.MatchDetails.xml : Contiene los detalles generales de un partido como pueden ser: Equipos que lo han jugado, resultado, calificaciones globales del equipo, goleadores, amonestados, etc. CódigoPartido.OpponentMatchLineup.xml : Contiene la alineación del equipo rival del usuario de la aplicación. Con datos tales como, qué jugador ha jugado en cada puesto, qué puntuación ha obtenido, con qué actitud ha jugado el equipo, etc. CódigoPartido.OwnMatchLineup.xml : Contiene información idéntica al anterior pero referente a la alineación del equipo del usuario de la aplicación. CódigoPartido.HTLive.xml: Contiene la información del reporte en forma de frases que se generan en el momento del desarrollo del partido. Se puede decir que es un modo texto de la información de un partido. Players.xml : Contiene la lista de jugadores que forman parte del equipo del usuario de la aplicación con el valor de todas sus características, además del nombre, edad, etc. En el Anexo A: Ficheros XML se encuentran algunos ejemplos de cada fichero xml con los que trabaja el sistema SEAH. 83

86 4.4. Filtrado de datos y preproceso En este apartado se contempla el descarte de ficheros, la selección y descarte de variables incluidas en los ficheros, el diseño de tablas de la base de datos para almacenar la información histórica de los partidos y estrategias para manejar campos de datos omisos. Primero de todo, hay que mencionar que para su mejor tratamiento, se van a ir leyendo todos los ficheros xml y se van a ir introduciendo en una base de datos. Por tanto se van a ir explicando las tablas y sus atributos según van apareciendo en los ficheros xml. Se ha decidido usar como gestor de base de datos mysql versión , ya que es una versión muy estable y se trata de un producto gratuito. Aunque a pesar de ser un producto gratuito es un gestor de base de datos capaz de manejar gran cantidad de datos sin ningún problema. 84

87 Descarte de ficheros. En este punto se decidió descartar el fichero HTLive.xml ya que no aporta información útil al objetivo de la aplicación. Como se ha visto, este fichero incluye un reporte del partido jugado en forma textual, pero no es otra cosa que redundancia de información respecto a los otros ficheros. En el juego, este fichero se utiliza para mostrar al usuario la información del partido de una forma más atractiva y entretenida, de forma que el jugador no tenga que leer una retahíla de números y códigos. Los datos que podrían ser útiles son el identificador del partido (que se consigue del fichero MatchDetails.xml), los identificadores de equipo (que se consigue de MatchDetails.xml) y la información referente a goles y amonestaciones (que también está incluida en MatchDetails.xml). Por tanto, este fichero se ha descartado de la tarjeta de datos ya que la información que ofrece está en el resto de ficheros xml. 85

88 Selección, descarte de variables y diseño de tablas. Los parámetros seleccionados de los ficheros MatchDetails son: MatchId: Identificador único de un partido, coincide con la primera parte del nombre del fichero. MatchType: Entero que define el tipo de partido conforme a los siguientes valores: 0 Partido de liga 1 Partido de promoción de ascenso o descenso 2 Partido de copa 3 Amistoso con reglas normales 4 Amistoso con reglas de copa 5 Actualmente sin uso 6 Hattrick masters 7 Amistoso internacional, reglas normales 8 Amistoso internacional, reglas de copa 9 Partido de competición de selecciones, reglas normales 10 Partido de competición de selecciones, reglas de copa 11 Amistoso de selecciones MatchDate: Fecha y hora del comienzo del partido. HomeTeamId: El identificador único del equipo que ha actuado como local HomeGoals: El número de goles marcados por el equipo local AwayTeamId: El identificador único del equipo que ha actuado como visitante AwayGoals: El número de goles marcados por el equipo visitante 86

89 Las siguientes variables (comienzan con Rating) se han seleccionado ya que ofrecen información sobre el rendimiento global de un equipo en ese partido por cada línea del campo. RatingMidfield: Valor entero que va de 1 a 80 que indica la puntuación global del centro del campo que ha obtenido el equipo local o visitante en función del tag donde se encuentre. RatingRightDef: Valor entero que va de 1 a 80 que indica la puntuación global de la defensa derecha del equipo local o visitante. RatingMidDef: Valor entero que va de 1 a 80 que indica la puntuación global de la defensa derecha del centro del campo del equipo local o visitante. RatingLeftDef: Valor entero que va de 1 a 80 que indica la puntuación global de la defensa izquierda del equipo local o visitante. RatingRightAtt: Valor entero que va de 1 a 80 que indica la puntuación global del ataque derecho del equipo local o visitante. RatingMidAtt: Valor entero que va de 1 a 80 que indica la puntuación global de ataque del centro del campo del equipo local o visitante. RatingLeftAtt: Valor entero que va de 1 a 80 que indica la puntuación global del ataque izquierdo del equipo local o visitante. TeamAttitude: Valor entero que representa la actitud del equipo para el partido. Sólo es visible para el equipo del cual es propietario el usuario. Los valores pueden se: -1 Jugar relajados 0 Normal 1 Partido de la temporada 87

90 TacticType: Valor entero que representa el tipo de táctica elegida para el partido. Los valores posibles son: 0 Normal 1 Presionar 2 Contraataques 3 Atacar por el centro 4 Atacar por las bandas 5 Jugar creativamente TacticSkill: Valor entero que representa la habilidad en la táctica elegida. WeatherId: Valor entero que representa el tiempo que ha hecho durante el partido. Influye en el rendimiento de los equipos. El valor puede ser: 0 Lluvioso 1 Nublado 2 Parcialmente nublado 3 Soleado ScorerPlayerId: Identificador único del jugador que ha marcado el gol. ScorerTeamId: Identificador del equipo al que pertenece el jugador que ha marcado el gol. ScorerHomeGoals: Número de goles que tiene el equipo local tras la consecución del tanto. ScorerAwayGoals: Número de goles que tiene el equipo visitante tras la consecución del tanto. ScorerMinute: Minuto en el que se ha conseguido el gol. 88

91 BookingPlayerId: Identificador único del jugador que ha sido amonestado. BookingTeamId: Identificador único del equipo al que pertenece el jugador amonestado. BookingType: Tipo de amonestación que ha recibido el jugador. Puede ser 1 si es tarjeta amarilla y 2 si es tarjeta roja. BookingMinute: Minuto en el que el jugador ha sido amonestado. PossessionFirstHalfHome: Posesión de balón en tanto por ciento del equipo local en la primera parte. PossessionFirstHalfAway: Posesión de balón en tanto por ciento del equipo visitante en la primera parte. PossessionSecondHalfHome: Posesión de balón en tanto por ciento del equipo local en la segunda parte. PossessionSecondHalfAway: Posesión de balón en tanto por ciento del equipo visitante en la segunda parte. Con la información seleccionada de estos ficheros, se han incluido cuatro tablas adicionales en la base de datos: Tabla Matches Atributos: matchid, matchtype, date, hometeamid, awayteamid, homegoals, awaygoals, scorerscount, bookingcount, PossessionFirstHalfHome, PossessionFirstHalfAway, PossessionSecondHalfHome, PossessionSecondHalfAway Clave primaria: matchid 89

92 Tabla Goals Atributos: matchid, teamid, playerid, scorerminute, scorerhomegoals, scorerawaygoals Clave primaria: matched, teamid, playerid, scorerhomegoals, scorerawaygoals Tabla Bookings Atributos: matchid, teamid, playerid, bookingtype, bookingminute Clave primaria: matchid, teamid, playerid, bookingtype Tabla Ratings Atributos: matchid, teamid, tactictype, tacticskill, ratingmidfield, ratingrightdef, ratingmiddef, ratingleftdef, ratingrightatt, ratingmidatt, ratingleftatt, teamattitude, experiencelevel Clave: matchid, teamid Nota: el atributo experiencelevel no se obtiene de MatchDetails si no de OwnMatchLineup u OpponentMatchLineup, pero se incluye en esta tabla ya que es un atributo que afecta al rendimiento del equipo y tiene impacto directo sobre las calificaciones. 90

93 Las variables descartadas del fichero MatchDetails son las siguientes: FinishedDate: la fecha de finalización del partido no tiene impacto en el objetivo del sistema HomeTeamName: el nombre del equipo local se obtiene de otro fichero xml AwayTeamName: el nombre del equipo visitante se obtiene de otro fichero xml Dress: los colores de la vestimenta no tiene ningún impacto en el desarrollo de un partido. ArenaId: el identificador del estadio no impacta en el objetivo del sistema ArenaName: el nombre del estadio no impacta en el objetivo del sistema El número de localidades vendidas afecta a la economía del equipo, pero no al desarrollo del partido, por este motivo se descartan estas cinco variables: SoldTerrace, SoldBasic, SoldRoof, SoldVIP, SoldTotal. 91

94 Los parámetros seleccionados de los ficheros OwnMatchLineUp y OpponentMatchLineUp son: MatchId: Identificador único de un partido. TeamId: Identificador del equipo referenciado por own u opponent según el fichero. TeamName: nombre del equipo. ExperienceLevel: experiencia media del equipo. PlayerId: identificador único de un jugador. RoleId: entero que indica que posición ha ocupado el jugador en un partido, antes de que haya ningún reposicionamiento (a través del behaviour o de una substitución). 1 portero 2 defensa lateral derecho 3 defensa central 1 4 defensa central 2 5 defensa lateral izquierdo 6 lateral derecho 7 medio central 1 8 medio central 2 9 lateral izquierdo 10 delantero 1 11 delantero 2 12 suplente portero 13 suplente defensa central 14 suplente medio central 15 suplente lateral 92

95 16 suplente delantero 17 faltas y penaltis 18 capitán 19 jugador reemplazado 1 20 jugador reemplazado 2 21 jugador reemplazado 3 PlayerName: nombre del jugador. RatingStars: decimal con la calificación del jugador en ese partido. PositionCode: entero que indica que posición ha ocupado el jugador en un partido, después de sufrir los reposicionamientos. 1 portero 2 defensa lateral derecho 3 defensa central 1 4 defensa central 2 5 defensa lateral izquierdo 6 lateral derecho 7 medio central 1 8 medio central 2 9 lateral izquierdo 10 delantero 1 11 delantero 2 Behaviour: entero que describe el comportamiento del jugador según los siguientes valores. 0 normal 93

96 1 ofensivo 2 defensivo 3 hacia medio 4 hacia lateral 5 extra delantero 6 extra medio central 7 extra defensor central Con la información seleccionada de estos ficheros, se han incluido las siguientes tablas adicionales en la base de datos: Tabla LineUps Atributos: matchid, teamid, playerid, roleid, ratingstars, positioncode, behaviour Clave primaria: matchid, teamid, playerid, roleid Tabla historicoequipos Atributos: teamid, teamname Nota: en la tabla de la base de datos se ha llamado a las variables idequipo, nombreequipo debido a la nomenclatura utilizada en la primera fase de desarrollo del proyecto Clave primaria: idequipo 94

97 Tabla historicojugador Atributos: playerid, playername Nota: en la tabla de la base de datos se ha llamado a las variables idjugador, nombrejugador debido a la nomenclatura utilizada en la primera fase de desarrollo del proyecto Clave primaria: idjugador Nota: el parámetro experiencelevel va incluido en la tabla Ratings descrita previamente. 95

98 Las variables descartadas de los ficheros OwnMatchLineUp y OpponentMatchLineUp son: HomeTeamId: se descarta ya que aparece en MatchDetails y se almacena en la base de datos desde ese fichero. HomeTeamName: se descarta ya que es información redundante con la almacenada por la tabla historicoequipo AwayTeamId: se descarta ya que aparece en MatchDetails y se almacena en la base de datos desde ese fichero. AwayTeamName: se descarta ya que es información redundante con la almacenada por la tabla historicoequipo MatchType: se descarta ya que aparece en MatchDetails y se almacena en la base de datos desde ese fichero. ArenaId: el identificador del estadio no impacta en el objetivo del sistema ArenaName: el nombre del estadio no impacta en el objetivo del sistema MatchDate: se descarta ya que aparece en MatchDetails y se almacena en la base de datos desde ese fichero. 96

99 Los parámetros seleccionados del fichero Players son: TeamId: identificador único de equipo. TeamName: nombre del equipo. PlayerId: identificador único de un jugador. PlayerName: nombre del jugador. Age: edad del jugador. PlayerForm: entero con el valor actual de la forma del jugador. Experience: entero con el valor actual de experiencia. Leadership: entero con el valor actual de liderazgo. Salary: salario del jugador. LeagueGoals: entero con el número de goles anotados en liga. CupsGoals: entero con el número de goles anotados en copa. FriendliesGoals: entero con el número de goles anotados en partidos amistosos. CareerGoals: entero con el número de goles anotados en toda su carrera. Specialty: entero que indica la especialidad del jugador según los siguientes valores. 0 Sin especialidad. 1 Técnico. 2 Rápido. 3 Potente. 4 Impredecible. 5 Cabeceador. Cards: número de tarjetas acumuladas. Devolverá 3 si está suspendido actualmente. InjuryLevel: número de semanas que el jugador estará lesionado. Si sólo está tocado el valor será 0, y si no tiene ningún tipo de lesión será -1. StaminaSkill: entero con el valor de la habilidad condición del jugador. 97

100 KeeperSkill: entero con el valor de la habilidad portería del jugador. PlaymakerSkill: entero con el valor de la habilidad jugadas del jugador. ScorerSkill: entero con el valor de la habilidad anotició del jugador. PassingSkill: entero con el valor de la habilidad pases del jugador. WingerSkill: entero con el valor de la habilidad lateral del jugador. DefenderSkill: entero con el valor de la habilidad defensa del jugador. SetPiecesSkill: entero con el valor de la habilidad balón parado del jugador. 98

101 Con la información seleccionada de estos ficheros, se han incluido las siguientes tablas adicionales en la base de datos: Tabla Jugadores Atributos: playerid, teamid, playername, age, playerform, experience, leadership, specialty, staminaskill, keeperskill, playmakerskill, passingskill, wingerskill, defenseskill, scoringskill, setpiecesskill, injurylevel, cards, marketvalue, leaguegoals, cupgoals, friendliesgoals, careergoals Nota: en la tabla de la base de datos se ha llamado a las variables idjugador, idequipo, nombre, edad, forma, experiencia, liderazgo, especialidad, condición, portería, jugadas, pases, lateral, defensa, anotación, balón parado, lesión, amonestación debido a la nomenclatura utilizada en la primera fase de desarrollo del proyecto. Clave primaria: playerid, teamid Tabla Equipo Atributos: teamid, teamname Nota: en la tabla de la base de datos se ha llamado a las variables idequipo, nombreequipo debido a la nomenclatura utilizada en la primera fase de desarrollo del proyecto. Clave primaria: teamid 99

102 Las variables descartadas del fichero Players son: PlayerNumber: el dorsal del jugador no es influyente en los partidos. TSI: el valor estimado del jugador no es influyente en los partidos. Statement: si el dueño del equipo ha hecho uso de la función lema no es influyente en los partidos. IsAbroad: que el jugador sea extranjero o no en el equipo en el que juega no es influyente en los partidos. Tampoco es revelante para el desarrollo de un partido el carácter del jugador (agreeability, agresiveness y honesty), los hattricks que haya logrado en su carrera (careerhattricks), si está en la lista de transferibles (TransferListed) o si ha sido seleccionado para un equipo nacional (NationalTeamId). 100

103 Formateo de variables especiales. Tras el análisis de los ficheros xml, se ha visto la necesidad de crear una serie de tablas en la base de datos con valores estáticos, los cuales van a dotar de significado a esa retahíla de números enteros. Así cuando se haga referencia a que un partido se ha jugado con clima 0 sabremos que se refiere a clima lluvioso. Las tablas estáticas que se han creado con su significado, son: Tabla weather Descripción: esta tabla guarda los distintos enteros posibles de weatherid y su descripción que pueden aparecer en la tabla matches. Atributos: weaterid, descripcion Clave primaria: weatherid Valores estáticos: 0 lluvioso 1 nublado 2 parcialmente nublado 3 soleado Tabla behaviour Descripción: esta tabla guarda los distintos enteros posibles de behaviour y su descripción que pueden aparecer en la tabla lineups. Atributos: behaviourid, descripcion Clave primaria: behaviourid 101

104 Valores estáticos: 0 normal 1 ofensivo 2 defensivo 3 hacia medio 4 hacia lateral 5 extra delantero 6 extra medio central 7 extra defensor central Tabla especialidad Descripción: esta tabla guarda los distintos enteros posibles de specialty y su descripción que pueden aparecer en la tabla jugadores Atributos: idespecialidad, descripcion Clave primaria: idespecialidad Valores estáticos: 0 Sin especialidad. 1 Técnico. 2 Rápido. 3 Potente. 4 Impredecible. 5 Cabeceador. 102

105 Tabla NivelesFormaLider Descripción: esta tabla guarda los distintos enteros posibles de playerform y de leadership así como su descripción que pueden aparecer en la tabla jugadores. Atributos: idfl, descripcion Clave primaria: idfl Valores estáticos: 0 desastroso. 1 horrible. 2 pobre. 3 debil. 4 Insuficiente 5 Aceptable 6 Bueno 7 Excelente Tabla NivelesHabilidad Descripción: esta tabla guarda los distintos enteros posibles de las distintas habilidades de los jugadores que aparecerán en la tabla jugadores y que son: condición., portería, jugadas, pases, lateral, defensa, anotación, balón parado y experiencia. Atributos: idhabilidad, descripcion Clave primaria: idhabilidad Valores estáticos: 1 desastroso. 2 horrible. 103

106 3 pobre. 4 debil. 5 Insuficiente 6 Aceptable 7 Bueno 8 Excelente 9 Formidable 10 Destacado 11 Brillante 12 Magnifico 13 Clase mundial 14 Sobrenatural 15 Titánico 16 Extraterrestre 17 Mítico 18 Mágico 19 Utópico 20 Divino Tabla PositionCode Descripción: esta tabla guarda los distintos enteros posibles del campo positioncode de la tabla lineups. Atributos: PositionCodeId, descripcion Clave primaria: PositionCodeId Valores estáticos: 104

107 1 portero 2 defensa lateral derecho 3 defensa central 1 4 defensa central 2 5 defensa lateral izquierdo 6 lateral derecho 7 medio central 1 8 medio central 2 9 lateral izquierdo 10 delantero 1 11 delantero 2 Tabla Role Descripción: esta tabla guarda los distintos enteros posibles del campo role de la tabla lineups. Atributos: roleid, descripcion Clave primaria: roleid Valores estáticos: 1 portero 2 defensa lateral derecho 3 defensa central 1 4 defensa central 2 5 defensa lateral izquierdo 6 lateral derecho 7 medio central 1 105

108 8 medio central 2 9 lateral izquierdo 10 delantero 1 11 delantero 2 12 suplente portero 13 suplente defensa central 14 suplente medio central 15 suplente lateral 16 suplente delantero 17 faltas y penaltis 18 capitán 19 jugador reemplazado 1 20 jugador reemplazado 2 21 jugador reemplazado 3 Tabla TacticType Descripción: esta tabla guarda los distintos enteros posibles del campo tactictype de la tabla ratings. Atributos: tactictypeid, descripcion Clave primaria: tactictypeid Valores estáticos: 0 Normal 1 Presionar 2 Contraataques 3 Atacar por el centro 106

109 4 Atacar por las bandas 5 Jugar creativamente Tabla TeamAttitude Descripción: esta tabla guarda los distintos enteros posibles del campo teamattitude de la tabla ratings. Atributos: teamattitudeid, descripcion Clave primaria: teamattitudeid Valores estáticos: -1 jugar relajados 0 normal 1 partido de la temporada Se ha creado además de estas tablas, otra tabla estática más llamada matchtype, pero esta tabla se va a describir en la siguiente etapa, la de reducción, ya que no se han cogido los valores que aparecían, sino que se ha hecho una reducción de los mismos para adaptarlos al problema de la aplicación. 107

110 Estrategias para manejar datos omisos En el proceso de lectura de ficheros xml y posterior inserción en la base de datos se han encontrado una serie de campos que en ocasiones no aparecen debido a que sólo son visibles para el propietario del equipo, o bien que determinados lances del juego hagan que sean visibles o no unos datos u otros. El desglose de cómo se han tratado estos datos y por qué es el tema que tratará este punto. TeamAttitude: el atributo teamattitude extraído de los ficheros MatchDetails, y almacenado en la tabla matches, sólo es visible para el dueño de un equipo de hattrick. Es decir, para un fichero MatchDetails dado, en la parte que describe las calificaciones de cada equipo, existirá un tag teamattitude sólo para uno de los equipos (el que sea dueño del equipo en hattrick), el local o el visitante, pero nunca para los dos. Esta omisión de información se ha decidido tratar de la siguiente forma; para el equipo que dispone del atributo teamattitude, el valor se almacena en la base de datos en su correspondiente registro. Para el equipo que no tiene el valor se almacena un

111 Role, PositionCode, Behaviour y RatingStars: estos cuatro atributos se obtienen de los ficheros OwnMatchLineUp y OpponentMatchLineUp, y aparecen por cada jugador que ha sido alineado. En una situación normal, se dispone de los cuatro atributos como puede observarse en el ejemplo: <Player ID=" " Index="5"> </Player> <PlayerID> </PlayerID> <RoleID>6</RoleID> <PlayerName>Edgar Alonso</PlayerName> <RatingStars>2</RatingStars> <PositionCode>6</PositionCode> <Behaviour>0</Behaviour> En este punto se presentan tres problemas, cada uno de ellos producido por una situación especial: 1 Jugador expulsado: si un jugador ha sido expulsado durante el partido, se pierden los atributos RatingStars, positioncode y behaviour. El playerid y playername tampoco aparece en la estructura xml, pero en este caso no se pierde ya que se consigue de otros ficheros. Se muestra un ejemplo de estructura xml de un jugador expulsado: <Player ID="0" Index="11"> <PlayerID>0</PlayerID> <RoleID>12</RoleID> <PlayerName></PlayerName> 109

112 </Player> En este caso, no se incluye el registro del jugador en la tabla lineups, pero se sabe que ha sido expulsado porque aparecerá en la tabla bookings (el bookingtype tendrá un valor de 2). Está información se cruzará durante el proceso de transformación para obtener los expulsados de un partido mas fácilmente durante el resto de pasos del proceso KDD. 2 Suplente que no juega: si un suplente no salta al campo durante un partido, los atributos RatingStars, positioncode y behaviuour están omisos. Ejemplo: <Player ID=" " Index="14"> <PlayerID> </PlayerID> <RoleID>15</RoleID> <PlayerName>Pasqual Soler</PlayerName> </Player> En este caso, se almacena la información de que disponemos en la tabla LineUps, y para los atributos perdidos se inserta un -2 (RatingStars, positioncode y behaviour). 3 Jugador lesionado: si un jugador se lesiona durante un partido y tiene que ser sustituido, se pierden los atributos positioncode y behaviour. El atributo ratingstars si que tiene valor ya que el jugador ha jugado algunos minutos y su calificación es válida. Ejemplo: 110

113 <Player ID=" " Index="18"> </Player> <PlayerID> </PlayerID> <RoleID>19</RoleID> <PlayerName>Diego Chasco Lafuente</PlayerName> <RatingStars>1</RatingStars> En este caso, se almacena la información de que disponemos en la tabla LineUps, y para los atributos perdidos se inserta un -2 (positioncode y behaviour). Nota: el motivo de haber seleccionado -2 es que los valores 0 y -1 son valores válidos para otros atributos de los ficheros; así, se ha establecido -2 como valor que indica nulo. 111

114 4.5. Proyección y reducción de datos Tal y como se ha comentado en la etapa anterior, se ha creado otra tabla estática llamada matchtype, pero que no contiene los valores tal y como aparecen en los ficheros xml, sino que se ha hecho una reducción de los mismos para adaptarlos a nuestro ámbito del problema y nuestro proceso KDD. Inicialmente los posibles valores de matchtype son: 1 Partido de liga 2 Partido de promoción de ascenso o descenso 3 Partido de copa 4 Amistoso con reglas normales 5 Amistoso con reglas de copa 6 Actualmente sin uso 7 Hattrick masters 8 Amistoso internacional, reglas normales 9 Amistoso internacional, reglas de copa 10 Partido de competición de selecciones, reglas normales 11 Partido de competición de selecciones, reglas de copa 12 Amistoso de selecciones Pero realmente no nos interesan todos estos valores, ya que por un lado hay identificadores numéricos sin uso y por otro para esta aplicación nos basta diferenciar entre partidos de copa, de liga, amistosos. Así los valores de la anterior tabla se han mapeado a: 112

115 Los valores: 1 y 2 (Partido de liga, Partido de promoción de ascenso o descenso) se tomarán como partido de liga. Los valores: 3 y 7 (Partido de copa, Hattrick Masters) se tomarán como partido de copa. Los valores 4, 5, 8 y 9 (Amistoso con reglas normales, Amistoso con reglas de copa, Amistoso internacional reglas normales, Amistoso internacional reglas de copa) se tomarán como partido amistoso. Los valores: 10, 11 y 12 (Partido de competición de selecciones reglas normales, Partido de competición de selecciones reglas de copa, amistoso de selecciones) se tomarán como partido de selecciones. Por tanto la tabla estática para tratar el matchtype queda de la siguiente forma: Tabla MatchType Descripción: esta tabla guarda los distintos enteros posibles del campo matchtype de la tabla matches. Atributos: matchtypeid, descripcion Clave primaria: matchtypeid Valores estáticos: 1 Partido de liga 2 Partido de copa 3 Partido Amistoso 4 Partido de selecciones 113

116 Transformación Con esta tabla, ya se puede decir que se tiene toda la información que se puede extraer de los ficheros xml de un equipo en la base de datos. Ahora nos enfrentamos al reto de intentar manipular toda esta información para poder hacerla más comprensible y que ayude en la toma de decisiones para conseguir la mejor alineación posible. Para ello, se va a realizar un proceso de transformación de todos los datos a otra tabla distinta en la base de datos que aglutine toda la información relevante para que ayude en la toma de decisiones. Se va a explicar a continuación como ha sido este proceso y que datos ha habido que unificar o reformatear para conseguir una mejor comprensión del problema. En primer lugar, analizando toda la información que existía en la base de datos, se ha visto que existen una serie de partidos que no aportan ninguna información al problema. Se trata de los partidos denominados en terminología hattrick walk over. Estos partidos se dan cuando un equipo se enfrenta a otro equipo que no tiene dueño. Es decir, que actualmente no es de ningún usuario. Cuando esto sucede, el equipo sin dueño presenta una alineación sin jugadores, el resultado del partido es de 5-0 a favor del equipo con dueño, y la posesión de balón es de cien por cien para el equipo que tiene dueño y cero por ciento para el equipo que no lo tiene. Por tanto estos partidos son inútiles para su análisis en el proceso de conseguir la mejor alineación, ya que es indiferente a quien alinee el equipo que tiene dueño, el resultado siempre será el mismo, ya que se enfrenta a un equipo fantasma. 114

117 Por otro lado, se ha visto que en los jugadores alineados como suplentes y que finalmente no han intervenido en el partido, su campo ratingstars tiene un valor -2, ya que no tenían valor y en la anterior etapa del proceso KDD se ha decidido que así sea. Estos jugadores no han intervenido en un partido y por tanto no tienen ningún valor para introducir en el proceso de conseguir la mejor alineación. Debido a este motivo, se ha decidido que estos jugadores sean eliminados del proceso de transformación. Además, analizando la forma en que hattrick utiliza los atributos role y behaviour, se ha llegado a la conclusión de que había que transformar esta información. Cómo se ha visto anteriormente, los valores del role hacen referencia a la posición que ocupa un jugador en el campo antes de aplicar modificadores a la propia variable role. Hay ciertos casos, en que estos valores resultan en información redundante que no aportan nada al sistema. Por ejemplo, los valores 3 y 4 del role hacen referencia a las posiciones defensa central 1 y defensa central 2. Cuando un jugador de hattrick se enfrenta al problema de establecer una alineación para un partido, sabe que puede necesitar dos defensas centrales, pero es indiferente si es defensa central 1 o 2, él necesita dos independientemente de la posición que vayan a ocupar. Ocurre lo mismo con los medios centrales o con los delanteros. En cuanto a los modificadores, el atributo behaviour tiene un impacto directo en el atributo role. Si a un role con valor 3 (defensa central 1) se le aplica un modificador behaviour con valor 5 (extra delantero), ese jugador no actuará como defensa, sino como delantero. Existen múltiples casos similares en que la posición del jugador queda modificada con distintos valores de los atributos role y behaviour. 115

118 Por estos motivos (redundancia y modificadores), se ha decidido crear un atributo adicional que simplifica el tratamiento de estos atributos de cara a su utilización en el sistema. Igualmente ha sido necesario crear una tabla estática adicional para poder mapear las combinaciones de role y behaviour con el valor de iddemarcacion. Tabla MapeoDemarcaciones Atributos: roleid, behaviourid, iddemarcacion Clave primaria: roleid, behaviourid Valores estáticos: a continuación se muestra la tabla completa. roleid behaviourid iddemarcacion

119 El atributo iddemarcacion es clave en su propia tabla, en la que mapea con la descripción del identificador de la demarcación de cara a la interfaz de usuario. Tabla Demarcaciones Atributos: iddemarcacion, descripcion Clave primaria: iddemarcacion Valores estáticos: 1 portero 2 defensa lateral 3 defensa central 4 medio centro 5 extremo 6 media punta 117

120 7 delantero centro Otro problema que se presenta para realizar la transformación, es que los jugadores expulsados sólo aparecen en la tabla bookings (aquellos que tienen bookintype con valor 2). En la primera parte de la transformación, se toman los datos de los jugadores a partir de la tabla lineups (en esta tabla, un jugador es la combinación de matchid, teamid y playerid), pero en la carga de datos a partir de los ficheros xml, no se pueden incluir en el lineup los jugadores expulsados porque el fichero que proporciona esta información no almacena el id del jugador que ha sido expulsado, simplemente tiene el role (posición en el campo) que ha sido expulsado. Está información sólo aparece en el apartado de amonestaciones de los detalles de un partido. Por este motivo, los expulsados de un partido hay que tratarlos en un proceso aparte ya que si no fuera así se perdería esta información que resulta útil para el objetivo principal del sistema. No se han incluido en está transformación las calificaciones globales de un equipo en las distintas líneas del campo, ya que la transformación está orientada al jugador y no al equipo (se quiere seleccionar los mejores jugadores en cada posición para formar un equipo titular). Aun así, en futuras fases puede utilizarse esta información ya que pueden aparecer patrones que indiquen que la presencia de un determinado jugador en un equipo titular pueda elevar una calificación de equipo en mayor o menor medida. De esta forma, tras llevar a cabo el proceso de transformación aparece una nueva tabla en la base de datos llamada transformación con las siguientes características: 118

121 Tabla Transformacion Atributos: matchid, teamid, playerid, matchtype, weatherid, roleid, ratingstars, positioncode, behaviour, iddemarcacion, playerbookingcount, playergoalcount, tactictype, tacticskill, teamattitude, experiencelevel, possesionfirsthalf, possesionsecondhalf. Clave primaria: matchid, teamid, playerid 119

122 4.6. Elección de la función y algoritmo de Data Mining. Una vez se tiene preparada la tabla transformación con el conjunto de datos en bruto es necesario elegir la función y el algoritmo de data mining. Se ha decidido elegir funciones de ranking y funciones resumen que se ven reflejadas en la implementación del algoritmo que se describe a continuación. El conjunto de datos que alberga la tabla transformación contiene decenas de miles de registros, por tanto, cada vez que haya que utilizar los datos históricos para generar una alineación, se trabajará únicamente con los registros que tengan información sobre los jugadores del equipo del usuario que haya iniciado el proceso. De esta manera, en primer lugar se consultan en la base de datos los jugadores del equipo que están en disposición de jugar (no están lesionados ni amonestados). Por cada jugador seleccionable, se consulta la tabla transformación para extraer todos los registros en los que aparece ese jugador; y la tabla Ratings (que almacena los ratings globales de un equipo en un partido) para tener en cuenta en el calculo de la función ranking la aportación de ese jugador al rating global del equipo en un partido. En la siguiente figura, se observa con más claridad la información que se está extrayendo de la tabla transformación para posteriormente tratarla. 120

123 Jugadores de un equipo Jugador Jugador Registros de la tabla transformación Registro Registro Registro Registro Registro Registro Rating Rating Rating Rating globales en el partido que indica el registro de transformación Rating Rating Rating Figura 9. Estructura de datos obtenida de la tabla transformación Los ratings van a jugar un papel importante en la función ranking, ya que representan la aportación del jugador en un partido a los rating globales de un equipo. La tabla ratings guarda puntuaciones globales del equipo en un partido (ratingmidfield, ratingrightdef, ratingmiddef, ratingleftdef, ratingrightatt, ratingmidatt, ratingleftatt) que se aprovechan en función de cómo se ha clasificado un jugador (su demarcación): los porteros no se ven afectados en este caso, los defensas centrales han modificado durante el partido la variable ratingmiddef; los defensas laterales afectan las variables ratingrightdef, ratingleftdef; los medios centro la variable ratingmidfield; los extremos ratingrightatt, ratingleftatt; los media punta ratingmidfield y ratingmidatt; y finalmente los delanteros ratingmidatt. 121

124 Por tanto, el primer cálculo que se hace sobre cada registro de la tabla transformación que nos interesa viene dado según la demarcación de cada jugador y es la variable ratiodem: Defensa Lateral Defensa Central Medio Central Extremo Media Punta Delantero Centro media de los valores ratingleftdef y ratingrightdef valor de ratingmiddef valor de ratingmidfield media de los valores ratingleftatt y ratingrightatt media de los valores ratingmidfield y ratingmidatt valor de ratingmidatt La función ranking modificará estas variables ya que evidentemente el rating va a ser un parámetro más de la función al que se aplicará un multiplicador. Una vez se han realizado estos cálculos, se unen todos los registros de los jugadores del equipo con el que se está trabajando en una sola lista de registros que será la entrada para la función ranking. Además, si durante el análisis inicial de registros y jugadores, se observa que existe algún jugador que no aparece en el histórico de partidos, este jugador se almacena en una tabla temporal para tenerlo en cuenta más adelante. Esta tabla temporal responde a un problema que se puede presentar: el usuario acaba de realizar un fichaje de un jugador y se da la coincidencia que, por ejemplo, es el mejor delantero del equipo y que todavía no ha jugado ningún partido (por tanto, no estará en el histórico); el proceso anterior dejaría fuera de la alineación al mejor goleador del equipo simplemente por no tener referencias previas de su rendimiento. 122

125 El siguiente paso es la ejecución de la función ranking para todos los registros que se han filtrado y tratado. La función ranking obtendrá un valor que es calculado aplicando multiplicadores sobre distintas variables de cada registro dependiendo de la demarcación del jugador. Además, existen tres variables en los registros que es necesario normalizar para convertir el valor de la variable en un valor que tenga sentido para el sistema. Estas variables son bookingcount, matchtype y teamattitude que al normalizarse se convierten en pesobooking, pesomatchtype y pesoteanattitude: pesobooking Si bookingcount es 0, la función lo convierte en 1 Si bookingcount es 1, la función lo convierte en 1 Si bookingcount es 2, la función lo convierte en -1 Nota: cabe destacar que si bookingcount es 2 es que el jugador ha sido expulsado, por tanto se penaliza con un pesobooking negativo. pesomatchtype Si matchtype es 1 (liga), la función lo convierte en 1 Si matchtype es 2 (copa), la función lo convierte en 1 Si matchtype es 3 (amistoso), la función lo convierte en 0 Si matchtype es 4 (selecciones), la función lo convierte en 0 pesoteamattitude Si teamattitude es -1 (jugar relajados), la función lo convierte en 2 Si teamattitude es 0 (normal), la función lo convierte en 1 Si teamattitude es 1 (partido de la temporada), la función lo convierte en 0 123

126 Nota: en este caso se puntúa mas él que el equipo haya jugado relajado y menos si han jugado al máximo para dar más importancia a las puntuaciones en caso de que hayan jugado relajados porque se sabe que no han jugado en condiciones normales. Veamos como se aplica la función ranking en cada caso, cada fila de las tablas que se muestran a continuación son sumandos de la función ranking, y en cada fila la primera columna es la variable obtenida del registro y la segunda columna el multiplicador de la variable. Portero Portero ratingstars 0.8 pesobooking 0.15 goalcount 0.05 Defensa Lateral y Defensa Central Defensa central y lateral pesomatchtype 0.1 ratingstars 0.3 pesobooking 0.2 goalcount 0.15 pesoteamattitude 0.1 ratiodem

127 Medio Centro Medio Centro pesomatchtype 0.1 ratingstars 0.3 pesobooking 0.15 goalcount 0.1 pesoteamattitude 0.1 ratiodem 0.15 possesion 0.1 Extremo Extremo pesomatchtype 0.1 ratingstars 0.3 pesobooking 0.15 goalcount 0.17 pesoteamattitude 0.1 ratiodem 0.15 possesion 0.03 Media Punta Media Punta pesomatchtype 0.1 ratingstars 0.3 pesobooking 0.15 goalcount 0.18 pesoteamattitude 0.1 ratiodem 0.15 possesion 0.02 Delantero Centro Delantero Centro pesomatchtype 0.1 ratingstars 0.3 pesobooking 0.15 goalcount 0.2 pesoteamattitude 0.1 ratiodem

128 La función ranking nos da como salida la actualización de la variable ratioglobal por cada objeto que representa un registro de la tabla transformación que hay en memoria. Finalmente, una vez se ha calculado el ratio de cada registro histórico, se insertan en la base de datos todos los registros que tenemos en memoria en la tabla ratiohistorico que tiene la siguiente estructura: Tabla ratiohistorico Atributos: matchid, teamid, playerid, iddemarcacion, ratioglobal. Clave primaria: matchid, teamid, playerid 126

129 5. Integración del algoritmo estándar con el proceso KDD 127

130 En este apartado se explica como se mezclan los dos algoritmos explicados previamente para generar la mejor alineación posible. Por una parte se ha expuesto el algoritmo estándar, que calcula la mejor alineación partiendo únicamente de las habilidades de los jugadores y el número de jugadores que hacen falta de cada tipo (porteros, defensas centrales, etc.). Por otra parte está el algoritmo de data mining, que hace uso del proceso KDD, y así, tiene en cuenta el histórico de partidos que ha jugado un equipo a lo largo de su historia. La aplicación ofrecerá al usuario la selección del algoritmo que más le interese; por un lado podrá generar una alineación con el algoritmo estándar, o por el contrario podrá utilizar el algoritmo de data mining que mezclará en un mismo proceso el algoritmo estándar y el proceso KDD; la base del algoritmo de data mining es el algoritmo estándar, al que se le añadirá el conocimiento que se ha extraído del histórico de partidos con el proceso KDD. Como la base del segundo algoritmo es el primero, a nivel de código fuente se ha utilizado una variable booleana que nos indica el algoritmo a utilizar; si la variable tiene valor false, se ejecutará el algoritmo estándar sin tener en cuenta el histórico; si la variable tiene valor true, comenzará la ejecución del algoritmo estándar, pero existirán pasos intermedios que permitan mezclar la ejecución del algoritmo estándar con el conocimiento extraído del proceso KDD. Como se ha descrito anteriormente, el algoritmo estándar realiza varias pasadas sobre el conjunto de jugadores que son seleccionables para elegir a los mejores; además lo 128

131 realiza en un determinado orden, en primer lugar genera una lista de porteros, luego una lista de medios centro, una lista de defensas centrales y así sucesivamente con las siete demarcaciones contempladas. Es en este paso, cuando entra en juego el conocimiento extraído del histórico de partidos. Por ejemplo, el caso de los porteros. El algoritmo estándar ha conseguido una lista de los mejores porteros del equipo, en este punto el algoritmo de data mining hará lo mismo, consultar la base de datos de históricos para obtener los porteros que han obtenido mayor ratio en un partido (el ratio global que ha calculado la función ranking en el apartado anterior). En este punto se presenta un problema, se han encontrado casos en el histórico de partidos de jugadores que han jugado de portero en algún partido sin que sea su demarcación ideal o secundaria sea portería. Estos casos no son significativos, ya que se ha observado que el ratio global de estos jugadores ha sido muy bajo, y por tanto puede considerarse como ruido extraído de nuestra base de datos. Se ha decidido limpiar estos casos comprobando que todos los jugadores de la lista tengan como posición ideal o secundaria la demarcación que se está buscando, en nuestro ejemplo portería. Tras realizar este filtrado de datos nos encontramos con dos listas de jugadores que se necesitan mezclar para seleccionar a los mejores en la demarcación portería. La primera lista tiene los mejores porteros teniendo en cuenta las habilidades del jugador (a partir de ahora vector seleccionables) y la segunda a los porteros que han tenido mejores actuaciones históricamente (a partir de ahora vector ratios). 129

132 El primer proceso sobre estas dos listas, es comparar qué jugadores hay en una y en otra. Se ha tomado la decisión de descartar a los jugadores que aparezcan en el vector ratios pero no aparezcan en el vector seleccionables ya que en el caso de los registros históricos no se dispone de la variable forma del jugador que es determinante para un partido. Sin embargo si que disponemos de la variable forma en el vector seleccionables. Además, esto puede representar un caso de un jugador que jugó en nuestro equipo, pero ha dejado de pertenecer al club bien porque se vendió, bien porque se le despidió. En este punto es necesario puntuar la posición que ocupa cada jugador en cada vector mediante una nueva función de ranking que como resultado genere una nueva lista de jugadores a partir de las dos listas anteriores El vector ratios es puntuado de la siguiente forma (recordemos que la primera posición tiene al jugador con más ratio global, la segunda al segundo mejor, la tercera al tercero mejor, etc.): Mejor portero 2º Mejor portero 3º Mejor portero 4º Mejor portero Figura 10. Función ranking para los mejores jugadores del histórico de partidos 130

133 La primera posición del vector tiene una puntuación de 100, la segunda de 90, la tercera de 80 y así sucesivamente. Si hubiera tantos jugadores en el vector como para llegar a cero, nunca se puntuará negativo, sino que se seguirá asignando un peso de cero. El vector seleccionables es puntuado de forma distinta, aunque también cumple el orden de posiciones: la primera posición del vector es el jugador con más puntuación debido a sus habilidades, la segunda posición es el segundo mejor, etc Mejor portero 2º Mejor portero 3º Mejor portero 4º Mejor portero Figura 11. Función ranking para los mejores jugadores según los marcos Este vector es puntuado con pesos más grandes por lo que se ha comentado anteriormente, existen variables que no tenemos en los registros históricos pero que son determinantes (la forma por ejemplo). El algoritmo estándar si que dispone de estas variables ya que son datos actuales no disponibles en los registros históricos (por ejemplo, no sabemos que habilidad de jugadas tenia un determinado jugador en un partido que se jugó hace tres temporadas). El otro caso que puede darse es que el jugador ya no pertenezca al equipo. Si hubiera tantos jugadores en el vector como para llegar a cero, nunca se puntuará negativo, sino que se seguirá asignando un peso de cero. 131

134 Además, hay que tener en cuenta un caso concreto como puede ser el reciente fichaje de un buen jugador. Este jugador todavía no ha jugado ningún partido, y puede que sea el mejor del equipo, por tanto no es posible su descarte simplemente porque no haya registros históricos suyos. En la fase anterior se comentó que los jugadores que no tenían histórico de partidos se habían anotado en una tabla temporal llamada jugadoressinhistorico. Bien, si en el vector seleccionables hay algún jugador que aparezca también en esta tabla temporal, y además aparece en el vector en la primera o segunda posición (lo que significa que se ha clasificado con muy buen peso debido a sus habilidades), este jugador obtendrá la suma de cien puntos extra lo que hará que la función de ranking lo clasifique con muy buena puntuación lo que hará que aunque no tenga histórico, se le evalúe según sus verdaderas posibilidades. El último paso consiste en unir los dos vectores. La forma de hacerlo es mover los elementos del vector ratios al vector seleccionables manteniendo los pesos en los casos en que un jugador sólo aparezca en uno de los vectores, o sumando los pesos que se acaban de asignar si el jugador aparece en los dos vectores. Por último se ordena el vector según los pesos utilizando el algoritmo de la burbuja, y se devuelve el control al algoritmo estándar. Como se ha comentado anteriormente, este proceso se llevará a cabo por cada demarcación y siempre lo iniciará el algoritmo estándar proporcionando el vector de jugadores que él ha seleccionado. 132

135 Veamos un ejemplo para la demarcación dada (el algoritmo es genérico e independiente de la demarcación). El algoritmo estándar presenta el siguiente vector seleccionables, y de la tabla ratiohistorico se ha extraído y filtrado el vector ratios: 200 Vector seleccionables Jug Vector ratios Jug Jug 2 90 Jug Jug 3 80 Jug Jug 4 70 Jug Jug 5 60 Jug Jug 6 50 Jug Jug 7 Jug Jug Jug 9 Figura 12. Comparación de los vectores tras las puntuaciones de la función ranking Como se puede observar, el jugador 10 sólo está en el vector ratios, esto significa bien que el jugador perteneció a nuestro equipo y ya no forma parte de él o que su variable forma sea muy baja y por tanto no lo haya clasificado el algoritmo estándar. Para el resto de jugadores que aparecen en los dos vectores se recalculan sus pesos sumando las puntuaciones que han obtenido en un vector y en otro. De esta forma, el jugador 1 obtiene un peso de 200 por estar primero en el vector seleccionables más 90 por ser el segundo en el vector ratios, sumando un total de 290. El jugador 2 obtiene 190 puntos por ser segundo en el vector seleccionables más 70 puntos por ser cuarto en el vector ratios, sumando un total de 260. El resto de jugadores se calculan de la misma forma y el vector resultante ordenado según los pesos es el siguiente: 133

136 Vector resultante Jug 1 Jug 4 Jug 2 Jug 3 Jug 6 Jug 5 Jug 7 Jug 8 Jug 9 Figura 13. Jugadores seleccionados tras aplicar el algoritmo de data mining Una vez terminada la ejecución de este algoritmo y se devuelve el control al algoritmo estándar con el nuevo vector seleccionables que contiene una mezcla de jugadores seleccionados por el algoritmo estándar (qué selecciona en base a las habilidades según la demarcación) y jugadores extraídos gracias al conocimiento descubierto por el proceso KDD, el algoritmo estándar continua su ejecución seleccionando el numero de jugadores de una demarcación que necesita (por ejemplo, si necesita dos delanteros centro seleccionará los dos primeros del vector resultante) y así sucesivamente para todas las demarcaciones y el numero de jugadores que necesite para cada una. 134

137 6. Implementación 135

138 Una vez recogido y representado el conocimiento y elegido el motor de inferencias, solo resta implementar el sistema, para ello, en primer lugar hay que elegir el lenguaje de programación adecuado. Como sabemos, existen multitud de opciones, pero debido a haber elegido como representación del conocimiento los marcos, así como el decidir hacer la aplicación vía Web y mi propia experiencia con los lenguajes de programación, he elegido hacerlo en java, que sin lugar a dudas es el lenguaje que mejor acepta el concepto de marco, ya que es un visión claramente orientada a objetos. Además se ha optado por realizarlo todo con freeware, así, además de usar java como lenguaje de programación, se ha optado por MySQL como gestor de base de datos. Como servidor de aplicaciones se ha elegido Apache Tomcat. A continuación se muestran las versiones de todas las tecnologías empleadas para la implementación del proyecto. J2SE 1.5.0_10 MySQL Apache Ant Apache Tomcat Jakarta Struts Java 2 Standard Edition Gestor de base de datos API de Apache para desplegar aplicaciones J2EE Servidor web y de aplicaciones API de Apache que facilita la implementación del paradigma Model View Controller para aplicaciones J2EE Eclipse SDK Entorno de desarrollo 136

139 A grandes rasgos la aplicación será así: En primer lugar aparecerá una página Web donde se podrá o bien elegir crear un nuevo equipo de forma manual, o bien cargar un equipo a partir de los ficheros xml, o bien consultar los equipos que ya están cargados en la base de datos. Para la carga de los ficheros xml, los ficheros xml deberán residir en un mismo directorio tanto la información de todos los partidos como la información de los jugadores del equipo. Así, al sistema se le marca el fichero players.xml dentro de un directorio y leerá todos los ficheros xml incluidos en ese directorio para ir introduciendo toda la información en la base de datos. Una vez finalizada la carga de ficheros xml, el sistema permitirá que se ejecute la preparación de los históricos, es decir que se lance la fase de transformación y limpieza de datos descrito anteriormente en el proceso kdd. Tras esta fase, el sistema ya está listo para realizar alineaciones de ambos algoritmos, el denominado estándar y que está basado íntegramente en marcos, y el denominado con Data Mining, que es una mezcla del algoritmo estándar con el conocimiento extraído de los datos históricos. Una vez seleccionado un equipo o bien creado un equipo vía manual o a través de los ficheros xml, veremos otra página Web donde podremos ver los jugadores de un equipo y podremos añadir, modificar o eliminar jugadores. Además podremos seleccionar clasificar equipo para ejecutar el algoritmo de clasificación, que consiste en que para cada jugador, se tiene en cuenta sus habilidades y los marcos que definen una 137

140 demarcación, para posteriormente calcular para cada demarcación, qué valores obtiene ese jugador mostrando los resultados del algoritmo en pantalla y almacenándolos en la base de datos para su posterior tratamiento. Así mismo, si modificamos cualquier valor de las habilidades de un jugador, el sistema recalculará las demarcaciones y sus valores para ese jugador; lo mismo sucederá cuando introduzcamos un nuevo jugador, el sistema calculará conforme al valor de las habilidades que hemos introducido las demarcaciones con sus valores para ese jugador nuevo. Por otro lado, una vez se hayan clasificado los jugadores podremos seleccionar realizar alineación, al seleccionar esta opción el sistema nos mostrará en base a que algoritmo queremos calcular alineación. Una vez marcada la opción correspondiente el sistema nos pedirá que seleccionemos la formación para el cual queremos realizar la alineación, 4-4-2, 3-5-2, etc. Seguidamente el sistema nos pedirá que seleccionemos la colocación de los jugadores en el campo. Así, una vez elegida la formación y la colocación en el campo que se desea aplicar, el sistema en base a las habilidades, forma, si está lesionado o no, etc. nos mostrará la mejor alineación para la formación elegida. 138

141 6.1. Arquitectura del sistema. Se ha optado por la implementación de una arquitectura en tres capas, en la que quedan claramente diferenciadas la capa de interfaz de usuario, el motor de la aplicación y la capa de acceso a base de datos. La siguiente figura muestra una visión general del sistema implementado. Figura 14. Arquitectura funcional de SEAH Los paquetes de Java se distribuyen por la arquitectura de tres capas de la siguiente forma: Capa de interfaz de usuario: paquete Interfaz Web. Capa motor del sistema: paquetes motor, modelo y parser XML. Capa de acceso a base de datos: paquete DAO. 139

142 La figura 14 muestra flechas de tres colores que representan las relaciones básicas entre los paquetes según los procesos de ejecución posibles. Las flechas azules representan el acceso de todos los paquetes al paquete modelo. Aunque el paquete modelo pertenece a la capa de motor de la aplicación, contiene clases genéricas para el sistema como pueden ser Jugador, Equipo, Demarcación, etc. Por tanto el paquete modelo permite realizar la abstracción de los distintos objetos con los que tiene que trabajar el sistema. Las flechas verdes representan el proceso de carga de ficheros xml. A través de la interfaz web, el usuario se comunica con el motor de la aplicación, que será el encargado de iniciar el parseo de los ficheros xml a través del paquete Parser XML, quién lee los ficheros xml, los modela según las clases proporcionadas en el paquete modelo, e inserta esos datos en la base de datos para su posterior consulta y tratamiento. Por último, las flechas rojas representan el resto de procesos que puede llevar a cabo el usuario final de SEAH. Sea cual sea la funcionalidad utilizada del sistema, el flujo de información siempre es parecida; el paquete de Interfaz Web inicia una petición al paquete motor gracias al patrón Model-View-Controller implementado, y el motor de la aplicación instanciará las clases necesarias del paquete modelo y del paquete DAO para servir la petición que ha recibido de la interfaz de usuario. El paquete DAO contiene clases que proporcionan métodos de acceso a base de datos con sus correspondientes queries de consulta, inserción y borrado. Es el único paquete del sistema que accede a la base de datos. 140

143 El paquete motor proporciona clases que implementan toda la lógica del sistema. Clases contenidas en este paquete como por ejemplo AnalizadorDemarcacion, AnalizadorJugador, CalculadorPesos, etc. son parte del algoritmo de clasificación de jugadores. Las clases FiltroHistorico, KDDTransformer o Normalizador forman parte del proceso KDD implementado; y GeneradorAlineacion y DMComparadorHistorico son parte de los algoritmos de alineación (estándar y data mining). 141

144 7. Evaluación 142

145 Durante las distintas fases del proyecto se llevaron a cabo reuniones periódicas con el experto, motivadas principalmente por dos razones: En primer lugar, que el experto pudiera validar la veracidad de los resultados obtenidos. En segundo lugar, validar la utilidad real de los resultados de la aplicación. La pregunta que surge en este punto es la siguiente: puede un jugador de hattrick seguir las estimaciones de SEAH para afrontar los retos del juego con ciertas garantías? Las reuniones con el experto surgieron tras completar ciertos hitos en la implementación del sistema. Por tanto, los principales puntos a validar por el experto son los siguientes: Algoritmo de clasificación de jugadores. Algoritmo de cálculo de alineaciones siguiendo el razonamiento tradicional. Algoritmo de calculo de alineaciones que mezcla el razonamiento tradicional con técnicas de data mining. Evaluación del algoritmo de clasificación de jugadores Para la evaluación del algoritmo de clasificación se ha contado una vez más con la ayuda del experto, ya que los resultados que ofrece el sistema no son comparables con otros sistemas, sino que son necesarios los conocimientos de un especialista para validar la salida del algoritmo. 143

146 Por tanto, se mostró al experto la clasificación de jugadores de un equipo de hattrick utilizando SEAH y posteriormente él comentó en detalle un par de jugadores como ejemplo para la validación. Aquí se muestran estos dos ejemplos, seguidos del comentario del experto: Ejemplo 1: Jugador Zhao Yew Lai Habilidades del jugador: Zhao Yew Lai Condición insuficiente (5) Portería desastroso (1) Jugadas pobre (3) Pases aceptable (6) Lateral bueno (7) Defensa débil (4) Anotación aceptable (6) Balón Parado débil (4) Clasificado por SEAH cómo: delantero centro Comentario del experto: Se trata de un delantero centro. Vemos que sus mejores habilidades son lateral, anotación y pases. Aunque tiene más puntuación en la habilidad lateral (7), la anotación y los pases se compensan ya que tienen ambas un valor de aceptable (6). La otra opción sería utilizarlo como extremo ya que es bueno en lateral. Ejemplo 2: Jugador Jan Gyring Habilidades del jugador: Jan Gyring Condición aceptable (6) Portería desastroso (1) Jugadas pobre (3) Pases pobre (3) Lateral horrible (2) Defensa excelente (8) Anotación pobre (3) Balón Parado horrible (2) Clasificado por SEAH cómo: defensa central 144

147 Comentario del experto: Este jugador es claramente un defensa central. Su mejor habilidad es defensa que tiene un valor de excelente (8). Excepto la condición, el resto de habilidades no puntúan mas de un 3, con lo cual queda descartado como defensa lateral, aunque claro, sería la siguiente opción ya que la habilidad defensa tiene mucho peso también en los defensas laterales. Además, el valor aceptable (6) en la habilidad condición permitirá al jugador terminar los partidos sin que note mucho el cansancio físico. Tras validar uno por uno la clasificación de los jugadores de un equipo, el experto destacó muy positivamente la opción de consultar el log de pesos de clasificación, ya que aseguró que es muy útil de cara a buscar posiciones alternativas para los jugadores. Evaluación de los algoritmos de alineación. Para la evaluación de los algoritmos de alineación se ha llevado a cabo una implementación real de los resultados de SEAH en hattrick. Todo el proceso se ha realizado de forma manual ya que hattrick, a diferencia de otros juegos online no proporciona ninguna API para configurar las alineaciones de un equipo. El procedimiento que se ha seguido ha consistido en configurar las alineaciones de distintos equipos de hattrick a lo largo de cuatro meses, utilizando tanto SEAH como Hattrick Forever (aplicación que utilizaba el experto antes de involucrarse en este proyecto) en partidos alternos, para posteriormente realizar una toma de datos de las victorias, empates y derrotas de esos equipos y comparar los resultados de cada algoritmo y aplicación. 145

148 La siguiente figura muestra los resultados obtenidos por el experto con la aplicación que utilizaba tradicionalmente, Hattrick Forever. Se muestran dos tablas, una con el conteo y otra con los porcentajes de victorias, empates y derrotas. Hattrick Forever Victorias Empates Derrotas 18 Oficiales Amistosos Total % Victorias Empates Derrotas 18 Oficiales 55,56 % 22,22 % 22,22 % 15 Amistosos 53,33 % 6,67 % 40 % Total 54,54 % 15,15 % 30,3 % Figura 15. Toma de datos de la aplicación Hattrick Forever A continuación se muestra la tabla con los resultados obtenidos al realizar las alineaciones siguiendo los consejos de SEAH con el algoritmo estándar de marcos. A primera vista se observa alguna mejora en los números. SEAH Algoritmo estándar Victorias Empates Derrotas 18 Oficiales Amistosos Total % Victorias Empates Derrotas 18 Oficiales 66,67 22,22 11,11 15 Amistosos 66, ,33 Total 66,67 12,12 21,21 Figura 16. Toma de datos del algoritmo estándar de SEAH Al utilizar la alineación recomendada por el algoritmo estándar de SEAH, el número de victorias se ha incrementado en 4 en un total de 33 partidos, lo que supone un 146

149 incremento del 12,13%. Se ha obtenido un empate menos, lo que supone un decremento del 3,03%. Respecto a las derrotas, se han perdido 3 partidos menos al utilizar las alineaciones recomendadas por SEAH, lo que supone un decremento del 9,09%. Por último, se muestran las tablas con los números obtenidos al seguir los consejos de SEAH utilizando el algoritmo de data mining. De nuevo, a primera vista se observa una leve mejora respecto al algoritmo estándar se SEAH, y una mejora substancial respecto a los resultados de Hattrick Forever. SEAH Alg data mining Victorias Empates Derrotas 18 Oficiales Amistosos Total % Victorias Empates Derrotas 18 Oficiales 77,77 16,67 5,56 15 Amistosos 80 13,33 6,67 Total 78,78 15,15 6,06 Figura 17. Toma de datos del algoritmo de data mining de SEAH En la siguiente tabla se muestra una comparativa del algoritmo de data mining de SEAH frente al algoritmo estándar y el único algoritmo implementado por Hattrick Forever. Como se puede observar, los resultados del algoritmo de data mining son mucho mejores que los de Hattrick Forever, y algo mejores que los resultados del algoritmo estándar. 147

150 Comparación alg. Data mining frente a alg. estándar de SEAH y el de Hattrick Forever Conteo Incremento victorias Decremento Empates Decremento Derrotas SEAH: alg. Estándar Hattrick Forever % Incremento victorias Decremento Empates Decremento Derrotas SEAH: alg. Estándar 12,11 3,03 12,12 Hattrick Forever 24, ,24 Figura 18. Comparativa del algoritmo de data mining de SEAH contra el algoritmo estándar y la aplicación Hattrick Forever Cabe destacar que al utilizar el algoritmo de data mining de SEAH se han obtenido 8 victorias más que utilizando Hattrick Forever, lo que supone un 24,24% de incremento en las victorias. Igualmente, se han obtenido 8 derrotas menos, es decir, un 24,24% de decremento. 148

151 8. Planificación y presupuesto 149

152 8.1. Planificación Cómo se puede observar en el diagrama de Gantt de la página siguiente, el presente proyecto se ha llevado a cabo durante unos diez meses. Una vez se finalizaron las fases de análisis y diseño, comenzó la fase de implementación, que como se puede ver en el diagrama ha sido la que más tiempo ha llevado. La fase de validación y pruebas comenzó a las pocas semanas de iniciar la implementación. Esto es debido a que se ha seguido una metodología muy dinámica, que permite probar diferentes módulos según se van implementado y corregir errores sobre la marcha. Igualmente, la fase de documentación se ha realizado desde las primeras semanas y no ha terminado hasta las últimas semanas del proyecto ya que según se realizaban las distintas fases, se intentaba documentar su parte correspondiente. 150

153 Estudio de viabilidad Análisis y diseño Ingenieria del conocimiento KDD Implementacion FASES Adquisicion del conocimiento Representación del conocimiento Razonamiento Aprendizaje del dominio de la aplicación Creación de un subconjunto de datos objetivo Filtrado de datos y preproceso Proyección y reducción de datos Diseño del algoritmo de data mining SEAH: Integración del algoritmo de data mining Base de datos Motor de inferencia Interfaz de usuario Validación Documentación con el razonamiento tradicional Algorirmo de razonamiento tradicional Algoritmo de SEAH: integración de algoritmo de data mining con razonamiento tradicional Septiembre Octubre Noviembre Diciembre Enero Febrero Marzo Abril Mayo Junio Figura 19. Planificación. Diagrama de Gantt 151

154 8.2. Presupuesto El presupuesto total de SEAH se ha calculado en función de las horas dedicadas por cada persona implicada en el proyecto. A continuación se muestra una estimación del precio por hora de cada perfil que ha intervenido en el desarrollo del proyecto: Jefe de proyecto Analista Programador Experto 35 /hora 30 /hora 25 /hora 30 /hora La siguiente tabla muestra el desglose de los costes por perfil y horas así como el coste total generado. Horas/hombre Precio/hora Coste ( ) Jefe de proyecto Analista Programador Experto Coste Total Figura 20. Coste del proyecto 152

155 En cuanto a los costes tecnológicos, al haberse optado por el uso de software libre, el coste es de cero euros. Como se ha comentado en otros apartados, las tecnologías utilizadas para el desarrollo del proyecto han sido Java como lenguaje de programación, MySQL como sistema gestor de base de datos, Jakarta Tomcat como servidor de aplicaciones y Eclipse como entorno de desarrollo. Por tanto, el coste total del proyecto asciende a euros. 153

156 9. Conclusiones 154

157 Las técnicas de ingeniería del conocimiento tradicionales como pueden ser los marcos, son muy útiles en determinadas situaciones, de hecho se han utilizado estas técnicas para el desarrollo de dos algoritmos de este sistema (algoritmo de clasificación de jugadores y algoritmo de alineación estándar) con excelentes resultados. Estas técnicas resuelven determinados problemas, pero existen otros que quedan fuera su alcance. Tal caso, es en el que encontramos conjuntos de datos desproporcionados. El problema planteado, seleccionar a los jugadores que tuvieron mejores actuaciones en el histórico de partidos se ajustaba perfectamente a este caso. La tabla que se construyó al llegar a la mitad del proceso KDD constaba de cerca de registros, una cifra que se plantea poco eficaz para el análisis por un ser humano. Por tanto, el proceso KDD ha sido crítico para obtener un algoritmo que como se ha visto en apartados anteriores, ha obtenido resultados muy superiores a sistemas existentes y que ha conseguido mejorar al algoritmo de alineación que emplea marcos. Por último, cabe recordar las particularidades del juego en el que se base el presente proyecto. El jugador novato de hattrick se siente abrumado cuando recibe su equipo, mira la lista de jugadores y se pregunta en que posición del campo debe colocar a cada uno de ellos, y no sólo eso, sino: de los veintidós jugadores que tiene, que once saca a jugar para un determinado partido? En cualquier caso, SEAH no es la solución a todos los problemas que se presentan en hattrick. Como en cualquier juego, en hattrick también juega un papel importante el azar, lo que implica que aunque se obtenga el máximo rendimiento de este sistema, consiguiendo por un lado, una clasificación perfecta de jugadores por demarcación, y por otro, generar la alineación más competitiva posible con los jugadores de que se 155

158 disponen; no está garantizada la victoria en un partido ni mucho menos. Entran en juego muchísimas variables que quedan fuera del alcance de este proyecto como pueden ser el equipo contrario, los procedimientos y algoritmos internos de hattrick, que como ya se ha comentado no son públicos, u otros factores que quedan de la mano del azar como puede ser que durante un partido se lesione el jugador estrella de nuestro equipo o que debido a una expulsión, nuestra formación quede diezmada. Por otra parte, hay muchos aspectos del juego que han quedado fuera del alcance de los objetivos del proyecto por no tener una relación directa con la ingeniería del conocimiento, por ejemplo, la gestión económica del equipo, gestión de la plantilla (despido o venta de jugadores), fichajes, el tipo de entrenamiento para los jugadores, gestión de la cantera, etc. En el desarrollo del proyecto se han ido cumpliendo todos y cada uno de los objetivos marcados inicialmente. El objetivo principal del sistema desde un inicio ha sido que el sistema ayude al jugador de hattrick a sacar el máximo rendimiento de sus jugadores y que sea más sencilla la gestión de un equipo en hattrick. Este objetivo se ha cumplido en su totalidad ya que se ha conseguido implementar un sistema que ayude al jugador de hattrick a sacar el máximo rendimiento a los jugadores de su equipo y pueda resultar más sencilla la gestión de su equipo en hattrick. Cumplido este objetivo principal, lo que se ha pretendido en el desarrollo del proyecto ha sido profundizar en mayor medida en alguna técnica de ingeniería del conocimiento así como llegar a conocer y desarrollar un proceso de descubrimiento de conocimiento en base de datos. Este objetivo ha quedado ampliamente cumplido y es necesario decir 156

159 que se ha descubierto que tanto la ingeniería del conocimiento así como el proceso de descubrimiento de conocimiento en bases de datos pueden ayudar en muchos problemas reales. Sobre todo el proceso de descubrimiento de conocimiento de bases de datos puedes ser una herramienta muy útil en la actualidad, ya que cada vez existen más datos de todo tipo, debido al abaratamiento del espacio en almacenamiento y a que los sistemas informáticos actuales alcanzan a todos los aspectos de la vida diaria y almacenan una cantidad enorme de datos. A continuación se van a repasar los objetivos marcados inicialmente, para marcar el grado de cumplimiento de cada uno y poder concluir si se han alcanzado los resultados esperados o no en el desarrollo de este proyecto. 157

160 9.1. Grado de cumplimiento de los objetivos Se van a repasar a continuación cada uno de los objetivos marcados al inicio y evaluar el resultado obtenido en cada uno para marcar si se han cumplido o no todos y cada uno de ellos: Una ayuda real y rápida para el jugador de hattrick Este ha sido el principal objetivo desde el principio. El sistema tenía que servir para cualquier usuario de hattrick. Este objetivo se ha cumplido en su totalidad, ya que hemos obtenido una aplicación que sin lugar a dudas ayudará a cualquier usuario de hattrick en la gestión de su equipo. Profundizar en el desarrollo de un proceso de KDD El objetivo marcado de profundizar en el desarrollo de un proceso de descubrimiento de conocimiento en bases de datos también ha sido cumplido satisfactoriamente, ya que basándome en la literatura que hay al respecto, se ha seguido paso por paso todas las fases del proceso y se ha conseguido que la aplicación partiendo de una elevada cantidad de información sea capaz de tratarla y extraer conocimiento de una forma automática. Clasificación de los jugadores según sus características Este objetivo es fundamental para que cualquier jugador de hattrick pueda, de una manera muy rápida, ver por cada jugador de su equipo no sólo su posición ideal en el campo, sino un listado de todas las demarcaciones ordenadas de la mejor a la peor y puntuadas en función de los pesos dados a los marcos dentro del proceso de ingeniería 158

161 del conocimiento, en concreto en la fase de adquisición de conocimiento. Así se puede saber que rendimiento nos pude ofrecer cada jugador en función del valor de sus habilidades en cada demarcación dentro del terreno de juego. Generar una alineación en función de las habilidades de los jugadores y con una formación dada Este objetivo también se ha cumplido ampliamente, ya que el sistema permite tal y como se ha visto en la fase de validación obtener la mejor alineación posible en función de los valores de las habilidades de todos los jugadores de un equipo, una vez seleccionada la formación con la que se va a jugar. Este objetivo se ha conseguido gracias al proceso de ingeniería del conocimiento, ya que ha permitido la adquisición del conocimiento mediante marcos y se ha podido ponderar la actuación que va a tener cada jugador en una posición determinada dentro del terreno de juego. Generar una alineación basada en los datos históricos y en las habilidades de los jugadores con una formación dada Este último objetivo ha sido el que se ha cumplido gracias al desarrollo completo del proceso de descubrimiento de conocimiento en bases de datos y a su interrelación con el algoritmo utilizado para la consecución del anterior objetivo. Se ha conseguido que el sistema genere la mejor alineación posible, no sólo teniendo en cuanta el valor de las habilidades de cada jugador, sino teniendo en cuenta también sus actuaciones en otros partidos disputados anteriormente. Es evidente que cuanto más datos históricos, mayor conocimiento de las actuaciones en partidos pasados se puede obtener. 159

162 Por tanto, al repasar cada uno de los objetivos y cómo se han llevado a cabo en el desarrollo del proyecto, queda ampliamente demostrado que se han cumplido todos y cada uno de los objetivos marcados inicialmente. Pero no sólo eso sino que se puede decir que se han cumplido siguiendo la metodología marcada y de una forma muy eficaz. 160

163 BIBLIOGRAFÍA [Gómez, 97] Gómez, A.; Juristo, N.; Montes C.; Pazos, J.: Ingeniería del Conocimiento. Centro de Estudios Ramón Areces, Madrid, [Cuena, 86] Cuena, J. (ed.): Inteligencia Artificial: Sistemas Expertos. Alianza Editorial. Madrid, [Maté, 88] Maté, J. L., Pazos, J.: Ingeniería del conocimiento. SEPA. Córdoba, Argentina, [Pres, 99] Pressman, Roger S.: Ingeniería del Software. Un enfoque práctico. McGraw Hill. Madrid, 1999 [Fayyad, 96] Agrawal, R., Mannila, H., Srikant, R., Toivonen, H., and Verkamo, I. Fast discovery of association rules. In Advances in Knowledge Discovery and Data Mining, U. Fayyad, G. Piatetsky-Shapiro, P. Smyth, and R. Uthurusamy, Eds. AAAI/MIT Press, Cambridge, Mass.,

164 [Elder, 96] Elder, J., and Pregibon, D. A statistical perspective on KDD. In Advances in Knowledge Discovery and Data Mining, U. Fayyad, G. Piatetsky-Shapiro, P. Smyth, and R. Uthurusamy, Eds. AAAI/MIT Press, Cambridge, Mass., [Allamaraju, 2001] Professional Java Server Programming J2EE, 1.3 Edition by Subrahmanyam Allamaraju, Cedric Beust, Marc Wilcox, Sameer Tyagi, Rod Johnson, Gary Watson, Alan Williamson, John Davies, Ramesh Nagappan, Andy Longshaw, P. G. Sarang, Tyler Jewell, Alex Toussaint. Wrox Press [Cavannes, 2002] Programming Jakarta Struts by Chuck Cavaness. O Reylly, [Dubois, 2006] MySQL Cookbook by Paul DuBois. O'Reilly Media, Inc

165 REFERENCIAS WEB [HATT, 2007] [HFOR, 2007] [JAVA, 2007] [MSQL, 2007] [STRU, 2007] [ANT, 2007] [TOMC, 2007] [ECLI, 2007] [HATT, 2007] struts.apache.org ant.apache.org tomcat.apache.org

166 ANEXOS 164

167 ANEXO A: Sistemas expertos A.1. Introducción La IA comprende el estudio y creación de sistemas computarizados que manifiestan cierta forma de inteligencia: sistemas que aprenden nuevos conceptos y tareas, que pueden razonar y derivar conclusiones útiles acerca del mundo que nos rodea, sistemas que pueden comprender un lenguaje natural o percibir y entender una escena visual, y sistemas que realizan otro tipo de actividades que requieren de inteligencia humana. La IA es una ciencia que trata de la comprensión de la inteligencia y del diseño de máquinas inteligentes, es decir, el estudio y la simulación de las actividades intelectuales del hombre (manipulación, razonamiento, percepción, aprendizaje, creación). Desde el punto de vista de los objetivos, la IA puede considerarse en parte como ingeniería y en parte como ciencia: Como ingeniería, el objetivo de la IA es resolver problemas reales, actuando como un conjunto de ideas acerca de cómo representar y utilizar el conocimiento, y de cómo desarrollar sistemas informáticos. Como ciencia, el objetivo de la IA es buscar la explicación de diversas clases de inteligencia, a través de la representación del conocimiento y de la aplicación que se da a éste en los sistemas informáticos desarrollados. 165

168 A.2. Definición y características de los SE A.2.1. Definición de Sistema experto. Un sistema experto puede definirse como un sistema basado en los conocimientos que imita el pensamiento de un experto, para resolver problemas de un terreno particular de aplicación. Una de las características principales de los sistemas expertos es que están basados en reglas, es decir, contienen unos conocimientos predefinidos que se utilizan para tomar todas las decisiones. En Teoría estos sistemas son capaces de razonar siguiendo los mismos pasos que seguiría un especialista (experto) en determinada materia (medico, matemático, biólogo, etc.) cuando resuelve un problema propio de su campo de su disciplina. Por ello, el creador de un sistema experto tiene que comenzar por identificar y recoger del experto humano los conocimientos que este utiliza, pero sobre todo los conocimientos empíricos que se adquieren con la práctica. Dado que los programas están basados en el conocimiento un aspecto fundamental es la programación del conocimiento la cual hace uso de la representación explicita del conocimiento a usar por el sistema y de su interpretación y manipulación lógica por medio de métodos de inferencia que permiten deducir nuevo conocimiento a partir del que ya se dispone. Así, un sistema experto es un cuerpo de programas de ordenador que intenta imitar e incluso superar en algunas situaciones a un experto humano en un ámbito concreto de su actividad. No pretende, en absoluto, reproducir el pensamiento humano, sino simplemente la pericia de un profesional competente (téngase en cuenta que para construir un SE suele contar con 166

169 grandes expertos en la materia que incorporan su conocimiento al sistema). Esta pretensión es más sencilla ya que en algunos campos reducidos los expertos trabajan siguiendo reglas, aunque, generalmente, no sean conscientes de ello. En aquellos campos en los que no sea necesario aplicar la intuición ni el sentido común, los sistemas basados en el conocimiento han conseguido notables éxitos, consiguiendo en ocasiones ser más regulares y rápidos que los propios expertos. Los sistemas basados en el conocimiento desarrollados hasta hace poco constituyen la primera generación cuya característica común reside en la superficialidad del conocimiento que se incluye en el mismo. Los ingenieros de conocimiento (desarrolladores de los sistemas basados en el conocimiento) se limitan a incorporar en los sistemas la experiencia y criterios de los especialistas sin buscar las razones últimas en las que se basan. Actualmente existen sistemas más avanzados, sistemas de Segunda Generación, en la que el conocimiento se estructura en dos niveles. El primer nivel, de control (se suele aludir a él como metaconocimiento y las reglas que lo constituyen reciben el nombre de metarreglas), sirve para determinar la forma de utilizar el segundo nivel que es el que contiene el conocimiento de los expertos. A.2.2. Características de los Sistemas expertos. Para que un sistema actúe como un verdadero experto, es deseable que reúna, en lo posible, lo más importante de las características de un experto humano, esto es: Habilidad para adquirir conocimiento. Fiabilidad, para poder confiar en sus resultados o apreciaciones. Solidez en el dominio de su conocimiento. Capacidad para resolver problemas. 167

170 Dada la complejidad de los problemas que usualmente tiene que resolver un SE, puede existir cierta duda en el usuario sobre la validez de respuesta obtenida. Por este motivo, es una condición indispensable que un SE sea capaz de explicar su proceso de razonamiento o dar razón del por qué solicita tal o cual información o dato. A.2.3. Componentes de un sistema experto. Los principales componentes de un sistema experto son los siguientes: Base de Conocimiento Un SE posee el conocimiento del experto humano convenientemente formalizado y estructurado; esto es lo que se conoce como Base de conocimiento. Está constituido por la descripción de los objetos y las relaciones entre ellos, así como de casos particulares y excepciones. Algunos sistemas basados en el conocimiento incluyen metaconocimiento o conocimiento sobre el conocimiento, es decir, la capacidad para buscar en la base de conocimiento y abordar la resolución del problema de una manera inteligente usando diferentes estrategias para la resolución con sus condiciones particulares de aplicación. Es decir se trata de definir criterios mediante los cuales el sistema decide la estrategia de búsqueda a utilizar en función de unos datos iniciales. El conocimiento se puede representar mediante cálculo de predicados, listas, objetos, redes semánticas y/o reglas de producción. De todas ellas, las dos formas más usuales son las reglas de producción y los objetos. En cualquier caso, la elección de las técnicas de representación a utilizar dependerá del tipo de problema a resolver. Motor de Inferencia También llamado intérprete de reglas, es un módulo que se encarga de las operaciones de búsqueda y selección de las reglas a utilizar en el proceso de razonamiento. Por 168

171 ejemplo, al tratar de probar una hipótesis dada, el motor de inferencia irá disparando reglas que irán deduciendo nuevos hechos hasta la aprobación o rechazo de la hipótesis objetivo. Base de Hechos Se trata de una memoria temporal auxiliar que almacena los datos del usuario, datos iniciales del problema, y los resultados intermedios obtenidos a lo largo del proceso de resolución. A través de ella se puede saber no sólo el estado actual del sistema sino también cómo se llegó a él. Como ya se ha mencionado antes, es conveniente que esta información se maneje con bases de datos relacionales, en lugar de utilizar un sistema particular de almacenamiento. Interfaz de Usuario Todo sistema dispone de una interfaz de usuario, que gobierna el diálogo entre el sistema y el usuario. Para el desarrollo de estas interfaces algunas herramientas de desarrollo incorporan generadores de interfaz de usuario o bien se utilizan herramientas de desarrollo de interfaces gráficas existentes en el mercado. Otros módulos que forman parte de este tipo de herramientas son los siguientes: Módulo de comunicaciones En la actualidad la mayoría de los sistemas basados en el conocimiento no viven aislados sino que interactúan con otros sistemas por lo que son capaces de interactuar no solamente con el experto sino con estos sistemas, para poder recoger información o consultar bases de datos. Módulo de explicaciones Es una utilidad importante en la etapa de desarrollo ya que aporta una ayuda considerable al ingeniero del conocimiento para refinar el funcionamiento del motor de inferencia, y al experto a la hora de construir y verificar la coherencia de la base de 169

172 conocimiento. Sirve para explicar al usuario tanto las reglas usadas como el conocimiento aplicado en la resolución de un determinado problema. Módulo de adquisición de conocimiento Este módulo permite al ingeniero del conocimiento, y/o experto, la construcción de la base de conocimiento de una forma sencilla, así como disponer de una herramienta de ayuda para actualizar la base de conocimiento cuando sea necesario. Si bien estos módulos no existen en todos los sistemas basados expertos, o bien están desarrollados o implementados de maneras diferentes, la función que desempeñan es muy interesante en el desarrollo de estos sistemas. Así, el motor de inferencia y las interfaces, que incluyen la interfaz de usuario, el módulo de explicaciones y el módulo de adquisición del conocimiento, forman el esqueleto o sistema esencial, y que, separadas de las bases de conocimiento y de hechos, constituyen una herramienta software para el desarrollo de los sistemas basados en el conocimiento (shells). En la figura 1 se refleja la arquitectura de un SE. 170

173 Figura 21. Arquitectura de un sistema experto. Para profundizar más en toda la teoría de sistemas expertos se recomienda que se mire en la bibliografía, en concreto las referencias [Gómez, 97] y [Cuena, 86] 171

174 A.3. Descubrimiento de conocimiento en Bases de Datos (KDD) Según avanzamos hacia la era de la información digital, el problema de la sobrecarga de datos nos inquieta. Nuestra habilidad para analizar y comprender conjuntos masivos de datos queda muy atrás respecto a la habilidad para generar y almacenar información. Para soportar la extracción de conocimiento útil de los volúmenes de datos que crecen tan rápido, hace falta una nueva generación de herramientas y técnicas computacionales. Estas técnicas y herramientas son el objeto del campo emergente de knowledge discovery in databases (KDD) y data mining. Las grandes bases de datos de información digital son ubicuas. Datos de la caja registradora de la tienda del barrio, el dispositivo de autorización de su tarjeta de crédito, registros hospitalarios, patrones en sus llamadas telefónicas, y muchísimas aplicaciones generan flujos de registros digitales almacenados en bases de datos enormes, muchas veces llamadas data warehouses (almacenes de datos). El hardware y las bases de datos actuales permiten almacenamiento y acceso eficiente a bajo coste. No obstante, tanto si el contexto es empresarial, médico, científico o gubernamental, estos conjuntos de datos en crudo, son a priori poco valiosos. Lo que si es valioso, es el conocimiento que se puede inferir de esos datos y posteriormente utilizar. Por ejemplo, la base de datos de marketing de una empresa de productos de consumo puede producir conocimiento de relaciones entre ventas de ciertos productos y ciertos grupos demográficos. Este conocimiento puede ser utilizado para lanzar una nueva campaña de marketing focalizada con resultados financieros predecibles frente a campañas no focalizadas. Las bases de datos suelen ser un recurso muy utilizado pero 172

175 no se les saca su máximo rendimiento, estas bases de datos, explotadas, pueden producir beneficios substanciales. Este articulo da un repaso del emergente campo KDD y data mining, incluyendo enlaces con temas relacionados, una definición del proceso de descubrimiento del conocimiento, análisis de algoritmos básicos de data mining y un análisis sobre a que se enfrentan los profesionales de este campo. Análisis de datos manual nada eficiente El método tradicional de transformar datos en conocimiento se sustenta en el análisis e interpretación manual. Por ejemplo, en la industria farmacéutica, es bastante común para los especialistas analizar las tendencias y cambios actuales sobre datos farmacéuticos de forma trimestral. Los especialistas generan informes detallando el análisis a la empresa farmacéutica; mas tarde, el informe se utiliza como base para la toma de decisiones y planificación. En un campo completamente diferente, los geólogos investigan sobre imágenes de planetas y asteroides, catalogando y localizando cuidadosamente objetos geológicos de interés, como por ejemplo cráteres. Para estas y otras aplicaciones, este sondeo manual de un conjunto de datos, es lento, caro y altamente subjetivo. De hecho, este análisis manual se esta revelando inútil en muchos dominios ya que el volumen de datos crece exponencialmente. Las bases de datos están creciendo de dos formas: el numero N de registros, u objetos en la base de datos, y el numero d de campos, o atributos por objeto. Las bases de datos que contienen del orden de N=10 9 objetos son cada vez mas frecuentes en, por ejemplo, las ciencias astronómicas. El numero d de campos puede ser fácilmente del orden de 10 2 o 173

176 incluso 10 3 en las aplicaciones de diagnostico medico. Quién podría digerir billones de registros, cada uno con decenas o centenas de campos? De momento el verdadero valor de esos datos recaen en la habilidad de los usuarios para extraer informes útiles, destacar tendencias o eventos interesantes, soporte de decisiones basadas en análisis estadísticos e inferencia, y explotar los datos para conseguir objetivos de negocio, operacionales o científicos. Cuando la escala de manipulación, exploración e inferencia de datos crece por encima de las capacidades del ser humano, la gente suele mirar a las tecnologías de la información para automatizar este proceso. El problema de la extracción de conocimiento de bases de datos grandes contempla muchos pasos, que van desde la manipulación y obtención de los datos hasta fundamentos matemáticos e inferencia estadística, búsqueda y razonamiento. Investigadores y profesionales interesados en estos problemas han estado reuniéndose desde el primer Workshop sobre KDD en Aunque el problema de extracción de conocimiento a partir de datos no es nuevo, la automatización en el contexto de grandes bases de datos genera muchos problemas nuevos sin resolver. 174

177 Definiciones El encontrar patrones útiles en los datos se conoce por distintos nombres (incluyendo data mining) según las comunidades (Ej. extracción de conocimiento, descubrimiento de información, cosecha de información, arqueología de datos, y procesamiento de patrones de datos). El término "data mining" es muy utilizado por estadísticos, investigadores del campo de base de datos, y mas recientemente por el MIS y comunidades empresariales. Aquí se utiliza el término KDD para referirnos al proceso global de descubrir información útil a partir de unos datos. El data mining es un paso en concreto de este proceso (aplicación de algoritmos específicos para extraer patrones o modelos a partir de los datos). Los pasos adicionales en el proceso KDD, tales como la preparación de los datos, selección de los datos, limpieza de datos, incorporación de conocimiento apropiado, y la correcta interpretación de los resultados de esta minería asegura que se extrae conocimiento útil de ese conjunto de datos. La aplicación a ciegas de métodos de data mining (criticado directamente llamándolo "remover datos" en la literatura estadística) puede ser una actividad peligrosa que nos lleva a descubrir patrones sin sentido. KDD ha evolucionado y continua haciéndolo, desde la intersección de la investigación en campos como las bases de datos, aprendizaje de maquinas, reconocimiento de patrones, estadística, inteligencia artificial y razonamiento con lo incierto, adquisición de conocimiento para sistemas expertos, visualización de datos, descubrimiento de maquinas, descubrimiento científico, obtención de información y computación de alto rendimiento. Los sistemas de software KDD incorporan teorías, algoritmos y métodos de todos estos campos. 175

178 Las herramientas y teoría de base de datos proveen la infraestructura necesaria para almacenar, acceder y manipular estos datos. Un término popularizado recientemente como "Data warehousing", se refiere a la tendencia actual de negocio de recolectar y limpiar datos transaccionales para hacerlos disponibles para el análisis online y el soporte de decisiones. Un acercamiento bastante popular para el análisis de data warehouses es el llamado "Online Analytical Processing" (OLAP). Las herramientas OLAP se centran en ofrecer análisis de datos multidimensional, el cual es superior al de SQL (lenguaje estándar de manipulación de datos) en resúmenes y análisis computacionales en varias dimensiones. Mientras las herramientas OLAP actuales se centran en el análisis interactivo de los datos, esperamos que incluyan más componentes de descubrimiento automático en un futuro próximo. Las áreas afectadas por los modelos de inferencia de datos (incluyendo patrones de reconocimiento estadístico, estadística aplicada, aprendizaje de maquinas y redes neuronales) eran el objetivo de la mayor parte del trabajo inicial de KDD. KDD se sustenta en métodos de estas áreas para encontrar patrones en los datos del proceso de data mining del proceso KDD. La pregunta natural es: En que se diferencia KDD de todas estas áreas? KDD se centra en el proceso global de descubrimiento de conocimiento, incluyendo cómo se almacena y accede a esa información, cómo los algoritmos son escalables a conjuntos de datos masivos y aun axial ser eficientes, cómo los resultados son interpretados y mostrados, y cómo la interacción global hombremaquina puede ser modelada y conseguida. KDD hace especial énfasis en la búsqueda de patrones comprensibles que pueden ser interpretados como conocimiento útil o interesante. 176

179 La estadística tiene bastante en común con KDD. La inferencia de conocimiento tiene un componente estadístico fundamental. La estadística ofrece un marco y un lenguaje para cuantificar los resultados inciertos cuando alguien trata de inferir patrones generales a partir de un conjunto representativo de una población. Como se menciono anteriormente, el termino data mining ha tenido connotaciones negativas en la estadística de los años 60, cuando las técnicas de análisis de datos basadas en ordenadores se comenzaron a utilizar. La preocupación surgió sobre el hecho de que si alguien busca lo suficiente en un conjunto de datos (incluso datos generados aleatoriamente), puede encontrar patrones que pueden parecer estadísticos pero que realmente no lo son. Este hecho es de vital importancia para KDD. En los últimos años, se ha producido un progreso substancial en cuanto a comprender estos problemas por parte de la comunidad estadística, más importantes directamente para KDD. Por tanto, el data mining es un actividad legitima mientas se comprenda como hacerla adecuadamente. También se puede ver KDD como un camino mas largo para modelar que la estadística, que intenta proveer herramientas para automatizar (hasta cierto grado) el proceso completo del análisis de datos, incluyendo el arte estadístico de la selección de hipótesis. 177

180 El proceso KDD A continuación presentamos nuestra perspectiva (necesariamente subjetiva) de un marco único centrado en el proceso KDD. El objetivo es ofrecer una visión global de la variedad de actividades en este área multidisciplinaria y mostrar como encaja cada pieza. Definimos el proceso KDD como: El proceso no trivial consistente en identificar patrones en los datos que sean válidos, novedosos, potencialmente útiles y en último termino comprensibles. A lo largo de este artículo, el término patrón va más allá de su significado tradicional para referirse también a modelos o estructuras de datos. En esta definición, la información se compone un conjunto de hechos (por ejemplo ocurrencias en una base de datos), y el patrón es una expresión en algún lenguaje que describe un subconjunto de esos datos (o un modelo aplicable a ese subconjunto). El termino proceso implica que hay muchos pasos involucrados en la preparación de la información, búsqueda de patrones, evaluación de conocimiento, y refinamiento (todos ellos a lo largo de varias iteraciones). El proceso se asume como no trivial ya que va mas allá de cantidades computacionales cerradas, es decir, debe involucrar la búsqueda de estructuras, modelos, patrones o parámetros. Los patrones descubiertos deben ser válidos para generar nueva información que tenga cierto grado de certeza. También nos interesan patrones que sean novedosos (al menos para el sistema, y preferiblemente para el usuario) y potencialmente útiles para el usuario o tarea. Por ultimo, los patrones deberían ser comprensibles (si no lo son inmediatamente, al menos tras algo de postprocesamiento). 178

181 Esta definición implica que podemos definir medidas cuantitativas para evaluar los patrones extraídos. En muchos casos, es posible definir medidas de certeza (por ejemplo clasificación de precisión estimada) o utilidad (por ejemplo, beneficios, quizás en dólares ahorrados debido a unas mejores predicciones o incremento del rendimiento en los tiempos de respuesta de un sistema). Conceptos como novedoso o comprensible son mucho más subjetivos. Según el contexto, el que algo sea comprensible puede estimarse a través de su simpleza (por ejemplo numero de bits necesarios para describir un patrón). Un concepto importante, llamado de-interés (interesting-ness), suele tomarse como una medida global del valor de un patrón, combinando su validez, novedad, utilidad, y simplicidad. Las funciones de-interés pueden definirse explícitamente o pueden manifestarse implícitamente a través de un orden establecido sobre los patrones o modelos por el sistema KDD. El data mining es un paso en el proceso KDD que consiste en la enumeración de patrones (o modelos) sobre los datos, sujetos a alguna limitación aceptable en su eficacia computacional. Como los patrones enumerables partiendo de un subconjunto finito de datos son potencialmente infinitos, y ya que la enumeración de patrones involucra alguna forma de búsqueda en un gran espacio, los limites computacionales establecen fuertes limites en el subespacio que puede ser explorado por un algoritmo de data mining. 179

182 Figura 22. Pasos del proceso KDD. La figura 1 representa el proceso KDD (no hemos mostrado todas las posibles flechas para indicar los bucles que pueden, y de hecho se dan, entre cualquier pareja de pasos del proceso; tampoco se muestra el elemento de rendimiento del sistema. el cual utiliza conocimiento para tomar decisiones o acciones). El proceso KDD es interactivo e iterativo (con muchas decisiones por parte del usuario), y envuelve numerosos pasos, resumidos como: 1. Aprendizaje del dominio de la aplicación: incluye conocimiento previo relevante y los objetivos de la aplicación. 2. Creación de un subconjunto de datos objetivo: lo cual incluye la selección de un subconjunto de datos o el enfoque sobre un subconjunto de variables o muestra de datos sobre los que se realizará el descubrimiento. 3. Filtrado de datos y preproceso: incluye operaciones básicas, como la eliminación de ruido o de valores extremos si fuese apropiado, recolectar la información necesaria para modelar o contabilizar el ruido, seleccionar estrategias para manejar campos de datos omisos, y contabilizar información secuencial en el tiempo y cambios conocidos, así como identificar problemas con el SGBD, tales como tipos de datos, diseño y mapeo de valores perdidos o desconocidos. 180

183 4. Proyección y reducción de datos: contempla el encontrar formas útiles para representar los datos, dependiendo del objetivo de la tarea, y aplicando reducciones en la dimensionalidad o métodos de transformación para reducir el número efectivo de variables en consideración o para encontrar representaciones de los datos no variables. 5. Selección de la función de data mining: contempla el decidir el propósito del modelo derivado por el algoritmo de data mining (por ejemplo resumen, clasificación, regresión, y clustering). 6. Elección del algoritmo/s de data mining: contempla la selección de métodos a utilizar para buscar patrones en los datos, como decidir que modelos y parámetros serian apropiados (Ej., los modelos para datos categorizados son diferentes de los modelos vectoriales) y encontrar un método "a juego" con el criterio general del proceso KDD (ej. el usuario podría estar mas interesado en comprender el modelo que en sus capacidades de predicción). 7. Data mining: contempla la búsqueda de patrones de interés para una representación en particular o para un conjunto de representaciones; así como la clasificación en base a reglas o árboles, regresión, clustering, modelado secuencial, dependencias, y línea de análisis. 8. Interpretación: contempla la interpretación de los patrones encontrados y posiblemente el regreso a cualquiera de los pasos anteriores, así como una posible visualización de los patrones extraídos, eliminación de patrones redundantes o irrelevantes, y la traducción de aquellos que son útiles en términos comprensibles para los usuarios. 181

184 9. Uso del conocimiento extraído: contempla la incorporación de este conocimiento al sistema, tomando acciones basados en ese conocimiento, o simplemente documentándolo e informando a las partes interesadas, así como la comprobación y resolución de conflictos potenciales con conocimientos previamente tomados (o extraídos) como ciertos. La mayor parte del trabajo inicial sobre KDD estaba centrado principalmente en el paso de data mining. De todas formas, el resto de pasos son igual de importantes (si no más) para la aplicación con éxito del proceso KDD en la practica. Ahora nos centraremos en el componente de data mining, el cual ha recibido sin duda la mayor atención en la literatura sobre estos temas. Data mining Data mining contempla el ajuste de modelos o la determinación de patrones sobre los datos estudiados. Los modelos ajustados juegan el rol de conocimiento inferido. Decidir si los modelos reflejan o no conocimiento útil es parte del proceso interactivo global KDD para lo cual, el juicio subjetivo humano es normalmente necesario. Una amplia variedad y numero de algoritmos de data mining están descritos en los libros (en áreas como estadística, reconocimiento de patrones, aprendizaje de maquinas y bases de datos). De esta forma, un debate puede contemplar normalmente una larga lista de algoritmos aparentemente sin relación y muy específicos. Aquí tratamos de reducir ese punto de vista. La mayoría de algoritmos de data mining se pueden ver como composiciones de unas cuantas técnicas y principios básicos. Particularmente, los algoritmos de data mining se nutren de una mezcla específica de estos tres componentes: 182

185 El modelo. Existen dos factores relevantes: la función del modelo (ej. clasificación y clustering) y la forma representacional del modelo (ej. una función lineal de múltiples variables y una función Gaussiana de densidad probabilística). Un modelo contiene parámetros que deben ser determinados a partir de los datos. El criterio de preferencia. Una base para la preferencia por un modelo o un conjunto de parámetros sobre otro, dependiendo de los datos dados. El criterio es normalmente alguna forma de función ideal del modelo de datos, quizá suavizado para evitar la sobre-adecuación (overfitting), o generando un modelo con demasiados grados de libertad para encajar con los datos dados. El algoritmo de búsqueda. La especificación de un algoritmo para encontrar modelos o parámetros concretos, datos dados, un modelo (o familia de ellos), y un criterio de preferencia. Un algoritmo de data mining es normalmente una instanciación de los componentes modelo/preferencia/búsqueda (ej. un modelo de clasificación basado en una representación de árbol de decisión, un modelo de preferencia basado en similitud de datos, determinado por una búsqueda de greedy utilizando una heurística en particular). Los algoritmos generalmente difieren unos de otros en términos de representación del modelo (ej. lineal y jerárquicos), y las preferencias de modelo o métodos de búsqueda son normalmente similares. Los libros de aprendizaje de estos algoritmos normalmente no dejan claro la representación del modelo, criterios de preferencia, o el método de búsqueda empleado; normalmente se mezclan en la descripción de un algoritmo en particular. La vista reducida clarifica la contribución independiente de cada componente. 183

186 Funciones de modelo Las funciones más comunes de data mining actual son: Clasificación: mapea (o clasifica) un dato en una o varias categorías predefinidas. Regresión: mapeo de un dato contra una variable de valor real predictivo. Clustering: mapeo de un dato contra una de varias clases categóricas (o clusters) en las cuales las clases deben determinarse a partir de los datos (no como en la clasificación en la cual las clases están predefinidas). Los clusters se definen encontrando agrupaciones naturales de datos basado en métricas de similitud o modelos de densidad probabilística. Resumen: provee una descripción compacta dado un subconjunto de datos. Un ejemplo sencillo seria la media y la desviación típica de todos los campos. Funciones mas sofisticadas involucran reglas resumen, técnicas de visualización multivariable, y funciones relacionales entre variables. Las funciones resumen suelen utilizarse en análisis de datos de exploración interactiva y generación automática de informes. Modelado de dependencias: describe dependencias significativas entre variables. Existe a dos niveles: estructurado y cuantitativo. El nivel estructurado del modelo especifica (normalmente de manera grafica) que variables son dependientes de forma local; el nivel cuantitativo especifica la fuerza de esas dependencias utilizando algún tipo de escala numérica. Análisis de enlaces: determina las relaciones entre campos de la base de datos (Ej.: reglas de asociación para describir que objetos se compran 184

187 mas frecuentemente al mismo tiempo que otros objetos en los supermercados). El objetivo esta en derivar correlaciones multicampo que satisfagan umbrales de soporte y confianza. Análisis secuencial: modelan patrones secuenciales (Ej.: en datos dependientes del tiempo, como análisis de series de tiempo). El objetivo es modelar los estados del proceso generando la secuencia o extraer y reportar desviaciones y tendencias a lo largo del tiempo. Representación del modelo Las representaciones de modelo mas populares incluyen árboles de decisión y reglas, modelos lineales, modelos no lineales (Ej.: redes neuronales), métodos basados en ejemplos (Ej.: vecino mas cercano y métodos de razonamiento basado en casos), modelos gráficos de dependencias probabilísticas (Ej.: redes Bayesianas), y modelos de atributos relacionales. La representación del modelo determina tanto la flexibilidad del modelo para representar los datos como la interpretabilidad del modelo en términos humanos. Normalmente, los modelos mas complejos ajustaran mejor los datos pero también pueden ser mas difícil de comprender y ajustar correctamente al problema. Mientras los investigadores tienden a abogar por modelos complejos, los profesionales suelen utilizar modelos simples debido a su robustez e interpretabilidad. El criterio de preferencia de un modelo determina como de bueno es un modelo particular y si sus parámetros se ajustan a los criterios del proceso KDD. Normalmente, existe un criterio cuantitativo embebido en el algoritmo de búsqueda (Ej.: el máximo criterio de similitud para encontrar los parámetros que maximizan la probabilidad del dato estudiado). Igualmente, se suele usar un criterio implícito (que refleja la tendencia 185

188 subjetiva del analista en términos en los cuales los modelos se toman inicialmente en consideración) en las iteraciones mas externas del proceso KDD. Hay dos tipos de algoritmos de búsqueda: de búsqueda de parámetros, dado un modelo, y búsqueda de modelo sobre un espacio de modelos. La búsqueda de los mejores parámetros normalmente se reduce a una optimización del problema (Ej.: búsqueda del máximo global de una función no lineal en un espacio de parámetros). Los algoritmos de data mining tienden a apoyarse en técnicas relativamente simples de optimización (Ej.: gradiante descendiente), aunque en principio también se utilizan técnicas de optimización mas sofisticadas. Los problemas con mínimos locales también son comunes y se tratan de la forma usual (reinicios aleatorios múltiples y búsqueda de múltiples modelos). La búsqueda sobre un espacio de modelos se trata normalmente "a lo greedy". Un punto importante es que normalmente cada técnica resuelve mejor unos problemas que otros. Por ejemplo, los clasificadores de árbol de decisiones pueden ser muy útiles para encontrar estructuras en espacios alto-dimensionales así como en problemas con datos categóricos y mixtos continuos (ya que los métodos de árbol no requieren métricas de distancia). Aun así, los árboles de clasificación con umbrales univariables con fronteras de decisión no serán apropiados para problemas en los que la frontera de decisión real son funciones no lineales multivariables. Por tanto, no existe un método de data mining universal; la elección de un algoritmo en particular para una aplicación en concreto es mas bien un arte. En la practica, una gran parte del esfuerzo puesto en las aplicaciones puede ir dirigido a formular el problema adecuadamente (formular la pregunta correcta) mas que optimizar los detalles del algoritmo de un método de data mining en particular. 186

189 Los objetivos de alto nivel del data mining tienden a ser predictivos, descriptivos, o una combinación de predicción y descripción. Un objetivo puramente predictivo se centra en la exactitud de la habilidad predictiva. Un objetivo puramente descriptivo se centra en comprender el proceso de generación de datos subyacente (una sutil pero importante diferencia). En la predicción, el usuario seguramente no se preocupe de si el modelo refleja la realidad sino de que tenga potencia predictiva (Ej.: un modelo que combine indicadores financieros actuales de alguna forma no lineal para predecir los futuros ratios de cambio del dólar contra el marco alemán). Un modelo descriptivo, por otra parte, se interpreta como un reflejo de la realidad (Ej.: un modelo que relacione variables económicas y demográficas para utilizar los logros conseguidos en la educación como la base para recomendar políticas sociales y conseguir un cambio). En la practica, la mayoría de aplicaciones KDD demandan algún grado tanto de los modelos predictivos y descriptivos. Problemas de investigación y retos Las actuales investigaciones y retos en la aplicación de KDD incluyen lo siguiente: Conjuntos de datos masivos y de alta dimensionalidad. Cada vez es mas frecuente encontrarse con bases de datos multigigabyte con millones de registros y gran numero de campos (atributos y variables). Estos conjuntos de datos suponen espacios de búsqueda descomunales para inducir un modelo y aumenta las posibilidades de que un algoritmo de data mining encuentre patrones falsos que no son validos. Las posibles soluciones suponen la utilización de algoritmos realmente eficientes, muestreos, métodos de aproximación, procesamiento paralelo masivo, técnicas de 187

190 reducción de la dimensionalidad, y la incorporación de conocimiento a priori. Interacción del usuario y conocimiento a priori. Los analistas no son normalmente expertos en KDD, pero si persones responsables de dar sentido a los datos utilizando técnicas KDD. Ya que el proceso KDD es por definición interactivo e iterativo, es un reto el proveer un entorno de alto rendimiento y respuesta rápida que ayude a los usuarios en la selección adecuada y en el ajuste de las herramientas y técnicas apropiadas para conseguir sus objetivos. Se necesita poner más énfasis en la interacción maquina-hombre y menos énfasis en la automatización completa (con el objetivo de poder satisfacer a usuarios noveles y expertos). Muchos de los métodos KDD actuales y sus herramientas no son realmente interactivos y no incorporan fácilmente conocimiento previo sobre un problema de forma simple. El uso de conocimiento de campo es fundamental en todos los pasos del proceso KDD. Por ejemplo, los enfoques Bayesianos utilizan probabilidades a priori sobre los datos y distribuciones como una forma de representar conocimiento previo (véase [6] y el artículo de Glymour sobre la inferencia estadística para este punto en concreto). Otros utilizan las capacidades deductivas de las bases de datos para descubrir conocimiento que es utilizado mas tarde para guiar las búsqueda de data mining. Sobre-adecuación (overfitting) y evaluación del significado estadístico. Cuando un algoritmo busca los mejores parámetros para un modelo en particular utilizando un conjunto limitado de datos, éste puede sobreadecuar esos datos, obteniendo como resultado un rendimiento pobre del 188

191 modelo sobre los datos de prueba. Las posibles soluciones pasan por la referencia cruzado, regularización, y otras estrategias estadísticas sofisticadas. La evaluación adecuada del significado estadístico suele perderse cuando el sistema busca muchos posibles modelos. Los métodos simples de solventar este problema incluyen el ajuste del test estadístico como una función de la búsqueda (Ej.: ajustes de Bonferroni sobre tests independientes) y testeo aleatorio, aunque este área está prácticamente sin explorar. Perdida de información. Este problema es especialmente grave en las bases de datos empresariales. Pueden perderse atributos importantes si la base de datos no se diseño teniendo en mente el descubrimiento de conocimiento. La pérdida de datos puede deberse a un error de un operador, fallos del sistema o en las mediciones, o por causa de una revisión del proceso de recolección de datos a lo largo del tiempo (Ej.: incorporación de nuevas variables que hace pocos meses no eran consideradas importantes). Las posibles soluciones pasan por la utilización de estrategias estadísticas mas sofisticadas para identificar variables ocultas y dependencias. Comprensión de patrones. En muchas de las aplicaciones, es importante hacer descubrimientos de conocimiento compresible para los hombres. Las posibles soluciones pasan por la utilización de representación grafica, estructuración de reglas, generación de lenguaje natural, y técnicas para la visualización de datos y conocimiento. Las estrategias de refinamiento de reglas también pueden solucionar un problema relacionado: el conocimiento descubierto puede ser implícita o explícitamente redundante. 189

192 Gestión de datos y conocimiento variables. Los datos que cambian rápidamente (no son fijos) puede provocar que patrones que eran validos, ahora no lo sean. Además, las variables en estudio de una base de datos dada pueden ser modificadas, borradas, o aumentadas con nuevas medidas a lo largo del tiempo. Las posibles soluciones pasan por la utilización de métodos incrementales para la actualización de patrones y que traten el cambio como una oportunidad de descubrimiento utilizando este cambio para enfocar la búsqueda hacia patrones de cambio. Integración. Un sistema de descubrimiento independiente no será demasiado útil. Los típicos problemas de integración suelen ser: la integración con un SGBD (a través de una interfaz de queries), integración con hojas de cálculo y herramientas de visualización, y la integración de lecturas de sensores de tiempo real. Los entornos interactivos hombremaquina como los descritos por el proceso KDD permiten tanto descubrimiento por ordenador asistido por humanos, como el descubrimiento por humanos asistido por ordenador. El desarrollo de herramientas de visualización, interpretación, y análisis de los patrones descubiertos es de suprema importancia. Estos entornos interactivos pueden permitir soluciones practicas a muchos problemas del mundo real con bastante mas rapidez que si hombre y maquina trabajaran de forma independiente. Hay oportunidades potenciales y un gran reto para desarrollar técnicas para integrar las herramientas OLAP de la comunidad de las bases de datos y las herramientas de data mining de las comunidades estadísticas y de aprendizaje de maquinas. 190

193 Datos no estándar, multimedia y orientados a objetos. Una tendencia importante es que las bases de datos no albergan únicamente datos numéricos sino grandes cantidades de datos no estándar y multimedia. Los tipos de datos no estándar incluyen no numéricos, no textuales, geométricos, y datos gráficos, así como no estacionarios, temporales, espaciales, y datos relacionales, y también mezclas de campos categóricos y numéricos. La información multimedia puede ser formas libres de texto multilenguaje así como imágenes digitalizadas, video, y habla y audio. Estos tipos de datos están muy lejos del ámbito de la tecnología KDD actual. Conclusiones A pesar de su rápido crecimiento, el área de KDD esta todavía en su infancia. Hay muchos retos que alcanzar, pero se han logrado unos cuantos éxitos (vea los artículos de Brachman en aplicaciones empresariales y los de Fayyad en aplicaciones científicas). Debido a que las recompensas potenciales de la aplicación de KDD son muy altas, se ha producido una maratón para ofrecer productos y servicios en el mercado. Un gran reto al que se enfrenta este campo es evitar las falsas expectativas acosando tecnologías recién nacidas (y relacionadas, por ejemplo, la inteligencia artificial y las redes neuronales). Es responsabilidad de los investigadores y profesionales de este campo el asegurar que las contribuciones potenciales de KDD no se exageran y que los usuarios comprenden la verdadera naturaleza de estas contribuciones así como sus limitaciones. Los principales problemas del corazón de esta área continúan sin solución. Por ejemplo, los problemas básicos de inferencia estadística y descubrimiento continúan siendo igual 191

194 de complejos y desafiantes como siempre. Simular la capacidad de análisis y la habilidad del cerebro humano para sintetizar nuevos conocimientos a partir de una información, de momento es inalcanzable para ninguna maquina. No obstante, los volúmenes de datos que se analizaran en un futuro hacen de las maquinas una necesidad. Este nicho que supone utilizar maquinas como un añadido para el análisis y la esperanza de que los conjuntos de datos masivos contengan "pedazos" de conocimiento valioso, impulsa el interés y la investigación en esta área. La mezcla que hace KDD de varias áreas, crea un terreno fértil para el crecimiento de nuevas herramientas para gestionar, analizar, y finalmente tomar el control sobre el flujo de datos al que se enfrenta la sociedad moderna. El hecho de que esta área este impulsado por unas necesidades sociales y económicas es el ímpetu necesario para su continuo crecimiento. El chequeo real de aplicaciones reales actuará como un filtro para separar las teorías y técnicas útiles de aquellas que lo son menos. 192

195 ANEXO B: FICHEROS XML El presente anexo describe en profundidad cada fichero xml con los que trabaja SEAH. CódigoPartido.MatchDetails.xml <?xml version="1.0"?> <HattrickData> <FileName>matchDetails.asp</FileName> <Version>1.4</Version> <UserID>807595</UserID> <UserIsSupporter>1</UserIsSupporter> <UserHasClubHouse>0</UserHasClubHouse> <FetchedDate> :03:49</FetchedDate> <ActionType>view</ActionType> <ActionResult Success="1">OK</ActionResult> <Match> <MatchID> </MatchID> <MatchType>1</MatchType> <MatchDate> :00:00</MatchDate> <FinishedDate> :45:00</FinishedDate> <HomeTeam> <HomeTeamID>315025</HomeTeamID> <HomeTeamName>Survivor Team</HomeTeamName> <Dress>N000000</Dress> <HomeGoals>2</HomeGoals> <TacticType>0</TacticType> <TacticSkill>8</TacticSkill> <RatingMidfield>3</RatingMidfield> <RatingRightDef>11</RatingRightDef> <RatingMidDef>12</RatingMidDef> <RatingLeftDef>11</RatingLeftDef> <RatingRightAtt>9</RatingRightAtt> <RatingMidAtt>9</RatingMidAtt> <RatingLeftAtt>8</RatingLeftAtt> </HomeTeam> <AwayTeam> <AwayTeamID>315028</AwayTeamID> <AwayTeamName>floydians</AwayTeamName> <Dress>N101010</Dress> <AwayGoals>2</AwayGoals> <TacticType>0</TacticType> <TacticSkill>8</TacticSkill> <RatingMidfield>3</RatingMidfield> <RatingRightDef>7</RatingRightDef> <RatingMidDef>10</RatingMidDef> <RatingLeftDef>9</RatingLeftDef> <RatingRightAtt>8</RatingRightAtt> <RatingMidAtt>7</RatingMidAtt> <RatingLeftAtt>9</RatingLeftAtt> <TeamAttitude>1</TeamAttitude> </AwayTeam> <Arena> <ArenaID>315025</ArenaID> <ArenaName>Survivor Team Arena</ArenaName> <WeatherID>2</WeatherID> <SoldTotal>13869</SoldTotal> </Arena> <Scorers Count="4"> <Goal Index="0"> <ScorerPlayerID> </ScorerPlayerID> 193

196 </Match> </HattrickData> <ScorerPlayerName>Ancor Pesquera</ScorerPlayerName> <ScorerTeamID>315025</ScorerTeamID> <ScorerHomeGoals>1</ScorerHomeGoals> <ScorerAwayGoals>0</ScorerAwayGoals> <ScorerMinute>4</ScorerMinute> </Goal> <Goal Index="1"> <ScorerPlayerID> </ScorerPlayerID> <ScorerPlayerName>Francisco Barbado</ScorerPlayerName> <ScorerTeamID>315028</ScorerTeamID> <ScorerHomeGoals>1</ScorerHomeGoals> <ScorerAwayGoals>1</ScorerAwayGoals> <ScorerMinute>31</ScorerMinute> </Goal> <Goal Index="2"> <ScorerPlayerID> </ScorerPlayerID> <ScorerPlayerName>Martí Baucells</ScorerPlayerName> <ScorerTeamID>315028</ScorerTeamID> <ScorerHomeGoals>1</ScorerHomeGoals> <ScorerAwayGoals>2</ScorerAwayGoals> <ScorerMinute>65</ScorerMinute> </Goal> <Goal Index="3"> <ScorerPlayerID> </ScorerPlayerID> <ScorerPlayerName>JesúsJiménez</ScorerPlayerName> <ScorerTeamID>315025</ScorerTeamID> <ScorerHomeGoals>2</ScorerHomeGoals> <ScorerAwayGoals>2</ScorerAwayGoals> <ScorerMinute>78</ScorerMinute> </Goal> </Scorers> <Bookings Count="1"> <Booking Index="0"> <BookingPlayerID> </BookingPlayerID> <BookingPlayerName>Óscaraboulais</BookingPlayerName> <BookingTeamID>315025</BookingTeamID> <BookingType>1</BookingType> <BookingMinute>14</BookingMinute> </Booking> </Bookings> <PossessionFirstHalfHome>50</PossessionFirstHalfHome> <PossessionFirstHalfAway>50</PossessionFirstHalfAway> <PossessionSecondHalfHome>46</PossessionSecondHalfHome> <PossessionSecondHalfAway>54</PossessionSecondHalfAway> La primera parte del fichero son encabezados en donde aparece el nombre del fichero, fecha de descarga, etc. A partir del tag <Match> es donde aparece la información substancial del fichero. Que consta de: MatchId: Identificador único de un partido, coincide con la primera parte del nombre del fichero. MatchType: Entero que define el tipo de partido conforme a los siguientes valores: 194

197 0. Partido de liga 1. Partido de promoción de ascenso o descenso 2. Partido de copa 3. Amistoso con reglas normales 4. Amistoso con reglas de copa 5. Actualmente sin uso 6. Hattrick masters 7. Amistoso internacional, reglas normales 8. Amistoso internacional, reglas de copa 9. Partido de competición de selecciones, reglas normales 10. Partido de competición de selecciones, reglas de copa 11. Amistoso de selecciones MatchDate: Fecha y hora del comienzo del partido FinishedDate: Fecha y hora del fin del partido HomeTeamId: El identificador único del equipo que ha actuado como local HomeTeamName: El nombre del equipo que ha actuado como local HomeGoals: El número de goles marcados por el equipo local AwayTeamId: El identificador único del equipo que ha actuado como visitante AwayTeamName: El nombre del equipo que ha actuado como visitante AwayGoals: El número de goles marcados por el equipo visitante Dress: Tanto para el local como el visitante. Una cadena de 7 caracteres que indican el uniforma del equipo local o visitante, en función de donde se encuentre el tag. RatingMidfield: Valor entero que va de 1 a 80 que indica la puntuación global del centro del campo que ha obtenido el equipo local o visitante en función del tag donde se encuentre. 195

198 RatingRightDef: Valor entero que va de 1 a 80 que indica la puntuación global de la defensa derecha del equipo local o visitante. RatingMidDef: Valor entero que va de 1 a 80 que indica la puntuación global de la defensa derecha del centro del campo del equipo local o visitante. RatingLeftDef: Valor entero que va de 1 a 80 que indica la puntuación global de la defensa izquierda del equipo local o visitante. RatingRightAtt: Valor entero que va de 1 a 80 que indica la puntuación global del ataque derecho del equipo local o visitante. RatingMidAtt: Valor entero que va de 1 a 80 que indica la puntuación global de ataque del centro del campo del equipo local o visitante. RatingLeftAtt: Valor entero que va de 1 a 80 que indica la puntuación global del ataque izquierdo del equipo local o visitante. TeamAttitude: Valor entero que representa la actitud del equipo para el partido. Sólo es visible para el equipo del cual es propietario el usuario. Los valores pueden se: -1 Jugar relajados 0 Normal 1 Partido de la temporada TacticType: Valor entero que representa el tipo de táctica elegida para el partido. Los valores posibles son: 0. Normal 1. Presionar 2. Contraataques 3. Atacar por el centro 4. Atacar por las bandas 7. Jugar creativamente 196

199 TacticSkill: Valor entero que representa la habilidad en la táctica elegida. ArenaId: Identificador único del estadio en el cual se ha disputado el partido. ArenaName: Nombre del estadio en el cual se ha disputado el partido. WeatherId: Valor entero que representa el tiempo que ha hecho durante el partido. El valor puede ser: 0. Lluvioso 1. Nublado 2. Parcialmente nublado 3. Soleado SoldTotal: El número total de localidades vendidas. SoldTerrace: El número de localidades vendidas del tipo Tribuna. SoldBasic: El número de localidades vendidas del tipo Grada General. SoldRoof: El número de localidades vendidas del tipo Preferente. SoldVIP: El número de localidades vendidas del tipo Palco. Scorers: Tag que indica que comienza una enumeración de goles, tiene un atributo llamado Count, que indica el número de goles que hay en la enumeración. Goal: Tag que indica que comienza un elemento de tipo gol. ScorerPlayerId: Identificador único del jugador que ha marcado el gol. ScorerPlayerName: Nombre del jugador que ha marcado el gol. ScorerTeamId: Identificador del equipo al que pertenece el jugador que ha marcado el gol. ScorerHomeGoals: Número de goles que tiene el equipo local tras la consecución del tanto. 197

200 ScorerAwayGoals: Número de goles que tiene el equipo visitante tras la consecución del tanto. ScorerMinute: Minuto en el que se ha conseguido el gol. Bookings: Tag que indica que comienza una enumeración de amonestaciones, tiene un atributo llamado Count, que indica el número de amonestaciones que hay en la enumeración. Booking: Tag que indica que comienza un elemento de tipo amonestación. BookingPlayerId: Identificador único del jugador que ha sido amonestado. BookingPlayerName: Nombre del jugador que ha sido amonestado. BookingTeamId: Identificador único del equipo al que pertenece el jugador amonestado. BookingType: Tipo de amonestación que ha recibido el jugador. Puede ser 1 si es tarjeta amarilla y 2 si es tarjeta roja. BookingMinute: Minuto en el que el jugador ha sido amonestado. PossessionFirstHalfHome: Posesión de balón en tanto por ciento del equipo local en la primera parte. PossessionFirstHalfAway: Posesión de balón en tanto por ciento del equipo visitante en la primera parte. PossessionSecondHalfHome: Posesión de balón en tanto por ciento del equipo local en la segunda parte. PossessionSecondHalfAway: Posesión de balón en tanto por ciento del equipo visitante en la segunda parte. 198

201 CódigoPartido.OwnMatchLineup.xml y CódigoPartido.OpponentMatchLineup.xml Al ser los dos ficheros iguales pero uno con la alineación de nuestro equipo y otro con la alineación del equipo contrario, se va a mostrar como ejemplo uno sólo, ya que los campos para estos ficheros son los mismos independientemente del equipo al que haga referencia. <?xml version="1.0"?> <HattrickData> <FileName>matchLineup.asp</FileName> <Version>1.1</Version> <UserID>807595</UserID> <FetchedDate> :03:49</FetchedDate> <ActionType>view</ActionType> <MatchID> </MatchID> <HomeTeam ID="315025"> <HomeTeamID>315025</HomeTeamID> <HomeTeamName>Survivor Team</HomeTeamName> </HomeTeam> <AwayTeam ID="315028"> <AwayTeamID>315028</AwayTeamID> <AwayTeamName>floydians</AwayTeamName> </AwayTeam> <MatchType>1</MatchType> <Arena ID="315025"> <ArenaID>315025</ArenaID> <ArenaName>Survivor Team Arena</ArenaName> </Arena> <MatchDate> :00:00</MatchDate> <Team ID="315028"> <TeamID>315028</TeamID> <TeamName>floydians</TeamName> <ExperienceLevel>2</ExperienceLevel> <Lineup> <Player ID=" " Index="0"> <PlayerID> </PlayerID> <RoleID>1</RoleID> <PlayerName>David Claramunt</PlayerName> <RatingStars>0.5</RatingStars> <PositionCode>1</PositionCode> <Behaviour>0</Behaviour> </Player> <Player ID=" " Index="1"> <PlayerID> </PlayerID> <RoleID>2</RoleID> <PlayerName>Miquel Mas</PlayerName> <RatingStars>2</RatingStars> <PositionCode>2</PositionCode> <Behaviour>0</Behaviour> </Player> <Player ID=" " Index="2"> <PlayerID> </PlayerID> <RoleID>3</RoleID> <PlayerName>Alberto Tinto</PlayerName> <RatingStars>2</RatingStars> <PositionCode>3</PositionCode> <Behaviour>0</Behaviour> </Player> 199

202 <Player ID=" " Index="3"> <PlayerID> </PlayerID> <RoleID>4</RoleID> <PlayerName>Pablo Morales</PlayerName> <RatingStars>2.5</RatingStars> <PositionCode>4</PositionCode> <Behaviour>0</Behaviour> </Player> <Player ID=" " Index="4"> <PlayerID> </PlayerID> <RoleID>5</RoleID> <PlayerName>Francisco Barbado</PlayerName> <RatingStars>1.5</RatingStars> <PositionCode>5</PositionCode> <Behaviour>0</Behaviour> </Player> <Player ID=" " Index="5"> <PlayerID> </PlayerID> <RoleID>6</RoleID> <PlayerName>Ricardo Oliz</PlayerName> <RatingStars>1</RatingStars> <PositionCode>6</PositionCode> <Behaviour>0</Behaviour> </Player> <Player ID=" " Index="6"> <PlayerID> </PlayerID> <RoleID>7</RoleID> <PlayerName>Franck Cazeneuve</PlayerName> <RatingStars>1</RatingStars> <PositionCode>7</PositionCode> <Behaviour>0</Behaviour> </Player> <Player ID=" " Index="7"> <PlayerID> </PlayerID> <RoleID>8</RoleID> <PlayerName>José Mar Fernández</PlayerName> <RatingStars>2.5</RatingStars> <PositionCode>8</PositionCode> <Behaviour>0</Behaviour> </Player> <Player ID=" " Index="8"> <PlayerID> </PlayerID> <RoleID>9</RoleID> <PlayerName>José Ángel <RatingStars>2</RatingStars> <PositionCode>9</PositionCode> <Behaviour>0</Behaviour> </Player> Cobos</PlayerName> <Player ID=" " Index="9"> <PlayerID> </PlayerID> <RoleID>10</RoleID> <PlayerName>Manuel Iglesias</PlayerName> <RatingStars>1</RatingStars> <PositionCode>10</PositionCode> <Behaviour>0</Behaviour> </Player> <Player ID=" " Index="10"> <PlayerID> </PlayerID> <RoleID>11</RoleID> <PlayerName>Martí Baucells</PlayerName> <RatingStars>2</RatingStars> <PositionCode>11</PositionCode> <Behaviour>0</Behaviour> </Player> <Player ID="0" Index="11"> <PlayerID>0</PlayerID> <RoleID>12</RoleID> <PlayerName></PlayerName> 200

203 </Lineup> </Team> </HattrickData> </Player> <Player ID=" " Index="12"> <PlayerID> </PlayerID> <RoleID>13</RoleID> <PlayerName>Antonio Cento</PlayerName> </Player> <Player ID=" " Index="13"> <PlayerID> </PlayerID> <RoleID>14</RoleID> <PlayerName>César Valle</PlayerName> </Player> <Player ID=" " Index="14"> <PlayerID> </PlayerID> <RoleID>15</RoleID> <PlayerName>Fernando Alfaro</PlayerName> </Player> <Player ID=" " Index="15"> <PlayerID> </PlayerID> <RoleID>16</RoleID> <PlayerName>Gabriel Escrivà</PlayerName> </Player> <Player ID=" " Index="16"> <PlayerID> </PlayerID> <RoleID>17</RoleID> <PlayerName>José Mar Fernández</PlayerName> </Player> <Player ID=" " Index="17"> <PlayerID> </PlayerID> <RoleID>18</RoleID> <PlayerName>José Mar Fernández</PlayerName> </Player> <Player ID=" " Index="18"> <PlayerID> </PlayerID> <RoleID>19</RoleID> <PlayerName>Diego Chasco Lafuente</PlayerName> <RatingStars>1</RatingStars> </Player> La primera parte del fichero son encabezados en donde aparece el nombre del fichero, fecha de descarga, etc. A partir del tag <Match> es donde aparece la información substancial del fichero. Que consta de: MatchId: Identificador único de un partido. 201

204 HomeTeamId: Identificador de equipo del equipo local. HomeTeamName: nombre del equipo local. AwayTeamId: Identificador de equipo del equipo visitante. AwayTeamName: nombre del equipo visitante. MatchType: Entero que define el tipo de partido conforme a los siguientes valores: 0. Partido de liga 1. Partido de promoción de ascenso o descenso 2. Partido de copa 3. Amistoso con reglas normales 4. Amistoso con reglas de copa 5. Actualmente sin uso 6. Hattrick masters 7. Amistoso internacional, reglas normales 8. Amistoso internacional, reglas de copa 9. Partido de competición de selecciones, reglas normales 10. Partido de competición de selecciones, reglas de copa 11. Amistoso de selecciones ArenaId: identificador del estadio donde se juega el partido. ArenaName: nombre del estadio donde se juega el partido. MatchDate: fecha y hora de inicio del partido. TeamId: Identificador del equipo referenciado por own u opponent según el fichero. TeamName: nombre del equipo. ExperienceLevel: experiencia media del equipo. LineUp: tag que nos indica que comienza una enumeracion de jugadores. Cada jugador tiene las siguientes propiedades: 202

205 PlayerId: identificador unico de un jugador. RoleId: entero que indica que posición ha ocupado el jugador en un partido, antes de que haya ningún reposicionamiento (a través del behaviour o de una substitución). 1. portero 2. defensa lateral derecho 3. defensa central 1 4. defensa central 2 5. defensa lateral izquierdo 6. lateral derecho 7. medio central 1 8. medio central 2 9. lateral izquierdo 10. delantero delantero suplente portero 13. suplente defensa central 14. suplente medio central 15. suplente lateral 16. suplente delantero 17. faltas y penaltis 18. capitán 19. jugador reemplazado jugador reemplazado jugador reemplazado 3 203

206 PlayerName: nombre del jugador. RatingStars: decimal con la calificación del jugador en ese partido. PositionCode: entero que indica que posición ha ocupado el jugador en un partido, después de sufrir los reposicionamientos. 1. portero 2. defensa lateral derecho 3. defensa central 1 4. defensa central 2 5. defensa lateral izquierdo 6. lateral derecho 7. medio central 1 8. medio central 2 9. lateral izquierdo 10. delantero delantero 2 Behaviour: entero que describe el comportamiento del jugador según los siguientes valores. 0. normal 1. ofensivo 2. defensivo 3. hacia medio 4. hacia lateral 5. extra delantero 6. extra medio central 204

207 7. extra defensor central CódigoPartido.HTLive.xml <?xml version="1.0"?> <HattrickData> <FileName>live.asp</FileName> <Version>1.2</Version> <UserID>807595</UserID> <FetchedDate> :03:49</FetchedDate> <ActionType>addMatch</ActionType> <MatchList> <Match Index="0"> <MatchID> </MatchID> <MatchDate> :00:00</MatchDate> <HomeTeam> <HomeTeamID>315025</HomeTeamID> <HomeTeamName>Survivor Team</HomeTeamName> </HomeTeam> <AwayTeam> <AwayTeamID>315028</AwayTeamID> <AwayTeamName>floydians</AwayTeamName> </AwayTeam> <EventList> <Event Index="1"> <Minute>0</Minute> <SubjectPlayerID>0</SubjectPlayerID> <SubjectTeamID>0</SubjectTeamID> <ObjectPlayerID>13869</ObjectPlayerID> <EventKey>32_2</EventKey> <EventText>13869 aficionados se reunieron en el estadio Survivor Team Arena. Fue uno de los días más agradables del año para ver jugar a sus ídolos, aunque el sol no terminó de iluminar el césped.&nbsp;</eventtext> </Event> <Event Index="2"> <Minute>0</Minute> <SubjectPlayerID>0</SubjectPlayerID> <SubjectTeamID>315025</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>20_2</EventKey> <EventText>Survivor alineó a sus hombres mediante una formación &nbsp;</EventText> </Event> <Event Index="3"> <Minute>0</Minute> <SubjectPlayerID>0</SubjectPlayerID> <SubjectTeamID>315025</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>21_3</EventKey> <EventText>Alineación: Oromí - Casas Rodríguez, Laboulais, Sastre Miralles, López - Alonso, Costajussà, Tizón, Sánchez - Pesquera, Jiménez.<br /><br /></EventText> </Event> <Event Index="4"> <Minute>0</Minute> <SubjectPlayerID>0</SubjectPlayerID> <SubjectTeamID>315028</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>20_2</EventKey> <EventText>floydians alineó a sus hombres mediante una formación &nbsp;</EventText> </Event> <Event Index="5"> <Minute>0</Minute> <SubjectPlayerID>0</SubjectPlayerID> <SubjectTeamID>315028</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>21_3</EventKey> 205

208 <EventText>Alineación: Chasco Lafuente - Mas, Tinto, Morales, Barbado - Oliz, Fernández, Cazeneuve, Cobos - Iglesias, Baucells.<br /><br /></EventText> </Event> <Event Index="6"> <Minute>4</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315025</SubjectTeamID> <ObjectPlayerID> </ObjectPlayerID> <EventKey>123_1</EventKey> <EventText>En el minuto 4, los locales se adelantaron en el marcador por 1-0 cuando <a href="playerdetails.asp?playerid= ">ancor Pesquera</a> remató un preciso centro que venía desde la banda derecha al segundo palo, donde nadie cubría.&nbsp;</eventtext> </Event> <Event Index="7"> <Minute>4</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315025</SubjectTeamID> <ObjectPlayerID> </ObjectPlayerID> <EventKey>231_2</EventKey> <EventText>Una jugada colectiva por el centro puso a <a href="playerdetails.asp?playerid= ">alejandro Tizón</a> en disposición de ampliar la ventaja local en el minuto 4, pero su disparo se estrelló en el cuerpo de un defensor.&nbsp;</eventtext> </Event> <Event Index="8"> <Minute>14</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315025</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>510_3</EventKey> <EventText>En el minuto 14, <a href="playerdetails.asp?playerid= ">óscar Laboulais</a> de Survivor recibió una tarjeta amarilla por una patada a destiempo.&nbsp;</eventtext> </Event> <Event Index="9"> <Minute>15</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315028</SubjectTeamID> <ObjectPlayerID> </ObjectPlayerID> <EventKey>95_2</EventKey> <EventText>floydians se vio forzado a realizar una sustitución cuando <a href="playerdetails.asp?playerid= ">diego Chasco Lafuente</a> no pudo seguir jugando debido a varios golpes que recibió durante el partido. El jugador que saltó a la cancha en su lugar fue <a href="playerdetails.asp?playerid= ">david Claramunt</a>.&nbsp;</EventText> </Event> <Event Index="10"> <Minute>31</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315028</SubjectTeamID> <ObjectPlayerID> </ObjectPlayerID> <EventKey>162_3</EventKey> <EventText>La afición fue mandada callar en el minuto 31 cuando el jugador de los visitantes, <a href="playerdetails.asp?playerid= ">francisco Barbado</a>, llegó con un tiro sorpresivo por la izquierda, nivelando el partido 1-1.&nbsp;</EventText> </Event> <Event Index="11"> <Minute>45</Minute> <SubjectPlayerID>0</SubjectPlayerID> <SubjectTeamID>0</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>45_3</EventKey> <EventText>Y con el resultado de 1-1 se llegó al término de los primeros 45 minutos.&nbsp;</eventtext> </Event> <Event Index="12"> <Minute>45</Minute> <SubjectPlayerID>0</SubjectPlayerID> <SubjectTeamID>0</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>47_2</EventKey> 206

209 <EventText>La lucha por el control del esférico estuvo muy igualada: la posesión fue del 50% para ambos conjuntos.<br><br>&nbsp;</eventtext> </Event> <Event Index="13"> <Minute>59</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315028</SubjectTeamID> <ObjectPlayerID> </ObjectPlayerID> <EventKey>271_2</EventKey> <EventText>floydians tuvo varias jugadas de gol, especialmente la del minuto 59, cuando <a href="playerdetails.asp?playerid= ">josé María Fernández</a> estuvo solo frente al portero <a href="playerdetails.asp?playerid= ">oriol Oromí</a>, quien consiguió detener el disparo.&nbsp;</eventtext> </Event> <Event Index="14"> <Minute>65</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315028</SubjectTeamID> <ObjectPlayerID> </ObjectPlayerID> <EventKey>109_1</EventKey> <EventText><a href="playerdetails.asp?playerid= ">alejandro Tizón</a> intentó hacerle un caño a <a href="playerdetails.asp?playerid= ">martí Baucells</a> que puso al público con los pelos de punta... porque estaba en la media luna de su propia área! El jugador de floydians se hizo con el balón y anotó ante la desesperada salida del portero, quien le gritó de todo menos guapo a su compañero. 1-2.&nbsp;</EventText> </Event> <Event Index="15"> <Minute>74</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315028</SubjectTeamID> <ObjectPlayerID> </ObjectPlayerID> <EventKey>280_3</EventKey> <EventText>Una jugada a balón parado en el minuto 74 casi se convirtió en un gol más para los visitantes, pero el árbitro consideró que el remate final se había producido en fuera de juego.&nbsp;</eventtext> </Event> <Event Index="16"> <Minute>77</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315028</SubjectTeamID> <ObjectPlayerID> </ObjectPlayerID> <EventKey>281_3</EventKey> <EventText>Después de 77 minutos, <a href="playerdetails.asp?playerid= ">franck Cazeneuve</a> estuvo cerca de aumentar la ventaja visitante con una volea bien colocada, pero finalmente el guardameta <a href="playerdetails.asp?playerid= ">oriol Oromí</a> pudo desviar.&nbsp;</eventtext> </Event> <Event Index="17"> <Minute>78</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315025</SubjectTeamID> <ObjectPlayerID> </ObjectPlayerID> <EventKey>113_2</EventKey> <EventText>Después de 78 minutos de partido, <a href="playerdetails.asp?playerid= ">jesús Jiménez</a> logró la igualada para Survivor tras un fino ataque por la derecha, colocando el marcador en un tensísimo 2-2. El partido se estaba poniendo muy emocionante!&nbsp;</eventtext> </Event> <Event Index="18"> <Minute>90</Minute> <SubjectPlayerID>0</SubjectPlayerID> <SubjectTeamID>315028</SubjectTeamID> <ObjectPlayerID>54</ObjectPlayerID> <EventKey>40_3</EventKey> <EventText>Los jugadores de floydians, quienes terminaron con una posesión del 54 por ciento, dominaron esta media parte.<br /><br /></EventText> </Event> <Event Index="19"> <Minute>90</Minute> 207

210 <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315025</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>41_3</EventKey> <EventText>El jugador más destacado de Survivor fue <a href="playerdetails.asp?playerid= ">ancor Pesquera</a>.&nbsp;</EventText> </Event> <Event Index="20"> <Minute>90</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315025</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>42_3</EventKey> <EventText>Sin embargo, <a href="playerdetails.asp?playerid= ">alejandro Tizón</a> no cumplió con las expectativas y fue el peor de su equipo.&nbsp;</eventtext> </Event> <Event Index="21"> <Minute>90</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315028</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>41_1</EventKey> <EventText>El mejor jugador de floydians fue <a href="playerdetails.asp?playerid= ">pablo Morales</a>.&nbsp;</EventText> </Event> <Event Index="22"> <Minute>90</Minute> <SubjectPlayerID> </SubjectPlayerID> <SubjectTeamID>315028</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>42_2</EventKey> <EventText>Por otro lado, <a href="playerdetails.asp?playerid= ">david Claramunt</a> tuvo un mal día y jugó por debajo del nivel de su equipo, no pudiendo cumplir como todos esperaban.&nbsp;</eventtext> </Event> <Event Index="23"> <Minute>90</Minute> <SubjectPlayerID>0</SubjectPlayerID> <SubjectTeamID>0</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>599_2</EventKey> <EventText>Resultado final: 2-2.&nbsp;</EventText> </Event> <Event Index="23"> <Minute>90</Minute> <SubjectPlayerID>0</SubjectPlayerID> <SubjectTeamID>0</SubjectTeamID> <ObjectPlayerID>0</ObjectPlayerID> <EventKey>599_2</EventKey> <EventText>Resultado final: 2-2.&nbsp;</EventText> </Event> </MatchList> </HattrickData> </EventList> <HomeGoals>2</HomeGoals> <AwayGoals>2</AwayGoals> </Match> La primera parte del fichero son encabezados en donde aparece el nombre del fichero, fecha de descarga, etc. A partir del tag <MatchList> es donde aparece la información substancial del fichero. Que consta de: 208

211 MatchId: Identificador único de un partido, coincide con la primera parte del nombre del fichero. MatchDate: fecha y hora de inicio del partido. HomeTeamId: El identificador único del equipo que ha actuado como local HomeTeamName: El nombre del equipo que ha actuado como local AwayTeamId: El identificador único del equipo que ha actuado como visitante AwayTeamName: El nombre del equipo que ha actuado como visitante HomeGoals: El número de goles marcados por el equipo local AwayGoals: El número de goles marcados por el equipo visitante EventList: Contenedor para tags del tipo Event. Event: Contenedor para los datos de un evento. Incluye un atributo llamado Index que actúa como contador. Minute: Minuto del partido en el que el evento se ha producido. EventKey: Índice que indica el tipo de evento. EventText: Cadena de caracteres que describe lo que ha sucedido en el evento tal y como aparece en el reporte de un partido. SubjectTeamId: Entero con el id del equipo protagonista del evento. SubjectPlayerId: Entero con el id del jugador protagonista del evento. ObjectPlayerId: Entero con el id del jugador que ha colaborado en el evento, bien abortando una ocasión de gol, bien asistiendo en un gol. 209

212 Players.xml <?xml version="1.0"?> <HattrickData> <FileName>players.asp</FileName> <Version>1.2.6</Version> <UserID>807595</UserID> <FetchedDate> :03:19</FetchedDate> <ActionType>view</ActionType> <Team> <TeamID>315028</TeamID> <TeamName>floydians</TeamName> <PlayerList Count="25"> <Player Index="0"> <PlayerID> </PlayerID> <PlayerName>Anton Brink</PlayerName> <PlayerNumber>100</PlayerNumber> <Age>20</Age> <MarketValue>1820</MarketValue> <TSI>1820</TSI> <PlayerForm>3</PlayerForm> <Statement></Statement> <Experience>1</Experience> <Leadership>2</Leadership> <Salary>18240</Salary> <IsAbroad>1</IsAbroad> <Agreeability>3</Agreeability> <Aggressiveness>1</Aggressiveness> <Honesty>3</Honesty> <LeagueGoals>0</LeagueGoals> <CupGoals>0</CupGoals> <FriendliesGoals>0</FriendliesGoals> <CareerGoals>2</CareerGoals> <CareerHattricks>0</CareerHattricks> <Specialty>0</Specialty> <TransferListed>0</TransferListed> <NationalTeamID>0</NationalTeamID> <CountryID>12</CountryID> <Caps>0</Caps> <CapsU20>0</CapsU20> <Cards>0</Cards> <InjuryLevel>-1</InjuryLevel> <StaminaSkill>3</StaminaSkill> <KeeperSkill>1</KeeperSkill> <PlaymakerSkill>4</PlaymakerSkill> <ScorerSkill>3</ScorerSkill> <PassingSkill>6</PassingSkill> <WingerSkill>2</WingerSkill> <DefenderSkill>9</DefenderSkill> <SetPiecesSkill>3</SetPiecesSkill> </Player> <Player Index="1"> <PlayerID> </PlayerID> <PlayerName>Carlos Huyarramendia</PlayerName> <PlayerNumber>100</PlayerNumber> <Age>18</Age> <MarketValue>1400</MarketValue> <TSI>1400</TSI> <PlayerForm>6</PlayerForm> <Statement></Statement> <Experience>1</Experience> <Leadership>5</Leadership> 210

213 <Salary>8000</Salary> <IsAbroad>0</IsAbroad> <Agreeability>3</Agreeability> <Aggressiveness>0</Aggressiveness> <Honesty>2</Honesty> <LeagueGoals>0</LeagueGoals> <CupGoals>0</CupGoals> <FriendliesGoals>0</FriendliesGoals> <CareerGoals>0</CareerGoals> <CareerHattricks>0</CareerHattricks> <Specialty>2</Specialty> <TransferListed>0</TransferListed> <NationalTeamID>0</NationalTeamID> <CountryID>35</CountryID> <Caps>0</Caps> <CapsU20>0</CapsU20> <Cards>0</Cards> <InjuryLevel>-1</InjuryLevel> <StaminaSkill>5</StaminaSkill> <KeeperSkill>1</KeeperSkill> <PlaymakerSkill>3</PlaymakerSkill> <ScorerSkill>4</ScorerSkill> <PassingSkill>5</PassingSkill> <WingerSkill>4</WingerSkill> <DefenderSkill>7</DefenderSkill> <SetPiecesSkill>2</SetPiecesSkill> </Player> </PlayerList> </Team> </HattrickData> 211

214 La primera parte del fichero son encabezados en donde aparece el nombre del fichero, fecha de descarga, etc. A partir del tag <Team> es donde aparece la información substancial del fichero. Que consta de: TeamId: identificador unico de equipo. TeamName: nombre del equipo. PlayerList: tag que indica el número de jugadores del equipo, además alberga tags del tipo Player. Player: contenedor de un jugador. Además contiene un índice que actúa como contador. PlayerId: identificador único de un jugador. PlayerName: nombre del jugador. PlayerNumber: dorsal del jugador. Age: edad del jugador. TSI: total skill index. Valor utilizado en hattrick para estimar el valor de un jugador. PlayerForm: entero con el valor actual de la forma del jugador. Statement: si el dueño del equipo es supporter, puede haber incluido un lema para sus jugadores. Experience: entero con el valor actual de experiencia. Leadership: entero con el valor actual de liderazgo. Salary: salario del jugador. IsAbroad: entero que indica si el jugador es extranjero en este equipo. 0 indica que no es extranjero, 1 que lo es. Agreeability: entero con el valor de carácter del jugador. 212

215 Aggresiveness: entero con el valor de agresividad del jugador. Honesty: entero con el valor de honestidad del jugador. LeagueGoals: entero con el número de goles anotados en liga. CupsGoals: entero con el número de goles anotados en copa. FriendliesGoals: entero con el número de goles anotados en partidos amistosos. CareerGoals: entero con el número de goles anotados en toda su carrera. CareerHattricks: entero con el número de hattricks (tres goles en el mismo partido) anotados en toda su carrera. Specialty: entero que indica la especialidad del jugador según los siguientes valores. 0. Sin especialidad. 1. Técnico. 2. Rápido. 3. Potente. 4. Impredecible. 5. Cabeceador. TransferListed: entero que vale 1 si el jugador está en la lista de transferibles o 0 si no lo está. NationalTeamId: si el jugador está seleccionado en un equipo nacional devuelve el identificador único de ese equipo, sino devuelve 0. Cards: número de tarjetas acumuladas. Devolverá 3 si está suspendido actualmente. InjuryLevel: número de semanas que el jugador estará lesionado. Si sólo está tocado el valor será 0, y si no tiene ningún tipo de lesión será -1. StaminaSkill: entero con el valor de la habilidad condición del jugador. 213

216 KeeperSkill: entero con el valor de la habilidad portería del jugador. PlaymakerSkill: entero con el valor de la habilidad jugadas del jugador. ScorerSkill: entero con el valor de la habilidad anotició del jugador. PassingSkill: entero con el valor de la habilidad pases del jugador. WingerSkill: entero con el valor de la habilidad lateral del jugador. DefenderSkill: entero con el valor de la habilidad defensa del jugador. SetPiecesSkill: entero con el valor de la habilidad balón parado del jugador. 214

217 ANEXO B: MANUAL DE INSTALACIÓN En este anexo se va a explicar cómo se deben instalar los distintos componentes para el correcto funcionamiento de la aplicación. En el cd adjunto se pueden encontrar todos los componentes necesarios. A continuación se muestra paso a paso el proceso de instalación. El sistema operativo sobre el que se ha desarrollado la aplicación y sobre el que se han realizado las distintas pruebas es Windows XP SP2. Instalación Java 1.5.0_10 En la carpeta software del cd adjunto puede encontrarse el ejecutable que instala la versión de java apropiada, en este caso jdk-1_5_0_10. Si se ejecuta el fichero jdk- 1_5_0_10-windows-i586-p.exe se lanza el asistente de instalación. A continuación se muestran capturas de la instalación: 215

218 Figura 23. Instalación de Java (I) Figura 24. Instalación de Java (II) 216

219 Figura 25. Instalación de Java (III) Figura 26. Instalación de Java (IV) 217

220 Figura 27. Instalación de Java (V) Figura 28. Instalación de Java (VI) 218

221 Figura 29. Instalación de Java (VII) Instalación Apache Tomcat En la carpeta software del cd adjunto también se encuentra la distribución del servidor de aplicaciones Apache Tomcat utilizada durante el desarrollo, concretamente la versión Para instalarlo basta con descomprimir el fichero jakarta-tomcat zip proporcionado y copiar la carpeta jakarta-tomcat extraída en el disco C de nuestro sistema. Se recomienda copiar esta carpeta en C: debido a que también se proporciona un script que facilita la configuración del servidor. 219

222 Variables de entorno Es necesario establecer variables de entorno tanto para el directorio de trabajo de Java como el de Apache Tomcat, además es necesario indicarle al sistema operativo donde están los binarios de ambos modificando la variable de entorno Path. Por tanto, las variables de entorno que se necesitan crear son las siguientes: Nombre de la variable CATALINA_HOME JAVA_HOME Valor C:\jakarta-tomcat C:\Program Files\Java\jdk1.5.0_10 Además, se añadirá lo siguiente en la variable PATH: %CATALINA_HOME%\bin;%JAVA_HOME%\bin; Config.bat En el cd adjunto también se proporciona un script que se encarga de configurar el servidor de aplicaciones, así como de copiar ficheros binarios del propio SEAH y ficheros xml de ejemplo en el disco de nuestro sistema. Por tanto, el siguiente paso en la instalación será la ejecución de este fichero bat. 220

223 El fichero bat hace lo siguiente: Copia el fichero tomcat-conf\seah.war que hay en el cd en el directorio webapps del servidor de aplicaciones, de forma que tomcat sea capaz de desplegar el sistema SEAH cuando arranque. Copia el fichero tomcat-conf\seah.xml que hay en el cd en el directorio conf\catalina\localhost del servidor de aplicaciones, de forma que tomcat sea capaz de crear un contexto para SEAH e inicializar el pool de conexiones contra la base de datos MySQL. Copia el directorio SEAH del cd en el disco C de nuestro sistema. Este directorio contiene entre otras cosas el código fuente de SEAH y el script que inicializa la base de datos entre otras cosas. Copia el directorio XML del cd en el disco C. Este directorio contiene ficheros de ejemplo xml con el histórico de partidos de cinco equipos para poder cargar fácilmente esta información en la base de datos. Finalmente copia el contenido del directorio C:\SEAH\web\WEB-INF\lib\ en la carpeta de tomcat C:\jakarta-tomcat \common\lib. En el proceso se copian librerías de java como por ejemplo struts (api del estándar Model- View-Controller), conector de MySQL para java, etc. Una vez se ha ejecutado el script config.bat, el servidor de aplicaciones quedará configurado. Veamos los últimos pasos. 221

224 Instalación del sistema gestor de base de datos MySQL. Se ha optado por MySQL como sistema gestor de base de datos ya que es gratuito y además ofrece funcionalidades similares a otros sistemas profesionales utilizados en entornos empresariales. Se ha elegido la versión por ser especialmente estable. Para comenzar la instalación hay que extraer el fichero mysql win32.zip de la carpeta software del cd y ejecutar el setup.exe que hay dentro. A continuación se muestran capturas del proceso de instalación. Figura 30. Instalación de MySQL(I) 222

225 Figura 31. Instalación de MySQL(II) Figura 32. Instalación de MySQL(III) 223

226 Figura 33. Instalación de MySQL(IV) En este punto se inicia el asistente de configuración de MySQL. Figura 34. Configuración de MySQL(I) 224

227 Figura 35. Configuración de MySQL(II) Figura 36. Configuración de MySQL(III) 225

228 Se marcan las casillas para que MySQL se instale como un servicio de Windows y para que las variables de entorno necesarias queden configuradas. Figura 37. Configuración de MySQL(III) 226

229 Se dejan los parámetros de seguridad por defecto. Figura 38. Configuración de MySQL(IV) Figura 39. Configuración de MySQL(V) 227

230 Figura 40. Configuración de MySQL(VI) Una vez se ha completado el asistente de configuración, MySQL ha quedado instalado y configurado para poder comenzar a utilizarlo. Dbinit.bat El último paso necesario antes de poder hacer uso de la aplicación, es inicializar la base de datos de SEAH. En la distribución de código fuente proporcionada se ha incluido un script de MySQL que es necesario ejecutar para la creación de tablas de la base de datos. En la carpeta raíz del cd proporcionado, se encuentra el fichero dbinit.bat que se encarga de lanzar el script de MySQL que inicializa la base de datos de SEAH. Es importante destacar que este script sólo se debe ejecutar si se quiere inicializar la base de datos por primera vez (como parte del proceso de instalación), o bien si se desea borrar toda la base de datos con la que se ha estado trabajando de una forma fácil. Por tanto, para terminar el proceso de instalación es necesario ejecutar el fichero dbinit.bat. 228

231 ANEXO C: MANUAL DE USUARIO Si se han seguido correctamente todos los pasos del manual de instalación, únicamente es necesario abrir un navegador web y dirigirse a la url: Al abrir la url nos aparecerá la pantalla inicial del sistema SEAH, tal y como se puede ver en la imagen: Figura 41. Página principal de SEAH Desde esta pantalla podemos elegir una de las siguientes tres opciones: Carga de ficheros xml Consultar equipos Alta de equipo 229

232 La opción consultar equipos, se utilizará cuando ya tenemos equipos en la base de datos y queremos consultarlos. Si no existe todavía ningún equipo en la base de datos, al seleccionar esta opción la aplicación nos muestra la siguiente pantalla: Figura 42. Listado de equipos vacío Si elegimos desde la pantalla de inicio la opción de alta de equipo, nos llevará al formulario para dar de alta un equipo de forma manual, algo que no es recomendado, debido a lo tedioso que puede resultar dar de alta todos los jugadores a mano. La pantalla que mostrará el sistema, será la siguiente: 230

233 Figura 43. Alta manual de equipo Si por el contrario seleccionamos la opción de carga de ficheros xml, nos aparecerá la siguiente pantalla para que introduzcamos el fichero players.xml: Figura 44. Carga de de ficheros xml Desde esta pantalla podemos o bien introducir manualmente la ruta y el nombre completo del fichero players.xml o bien seleccionado el botón browse nos abrirá un 231

234 cuadro de diálogo típico de selección de ficheros en nuestro ordenador, tal y como se muestra en la siguiente imagen: NOTA: Tal y como aparece en la imagen, es necesario que se coloquen todos los ficheros históricos de un equipo junto con el fichero players.xml en un mismo directorio. Figura 45. Selección del directorio de ficheros xml Una vez seleccionado el fichero players.xml el sistema nos muestra la pantalla anterior y deberemos pulsar en el botón submit para que se inicie el proceso de la lectura y carga en base de datos de todos los ficheros históricos del equipo así como las características de todos los jugadores contenidos en el fichero players.xml. Es necesario mencionar en 232

235 este punto que esta carga tardará más o menos minutos en función del número de ficheros históricos que se posean de cada equipo. Mientras se realiza todo el proceso de lectura de los ficheros xml y carga en base de datos de toda la información permanecerá la siguiente pantalla: Figura 46. Proceso de carga de ficheros xml Una vez ha terminado la carga de los ficheros, se muestra la página que contiene el listado de equipos que hay dados de alta en la base de datos: 233

236 Figura 47. Listado de equipos Desde está página se presentan varias opciones: Borrar equipo: elimina el equipo de la base de datos Preparar histórico de partidos: desde este enlace se inicia uno de los procesos que preparan la base de datos para poder extraer conocimiento de ella. El proceso puede tardar varios minutos dependiendo de la cantidad de partidos históricos que haya almacenados en la base de datos. Una vez termina el proceso, el enlace nos deja en la misma página (lista de equipos). 234

237 Figura 48. Preparando el histórico de partidos Ver equipo: está opción nos permite ver la lista de jugadores de nuestro equipo con todos sus detalles. Las siguientes capturas muestran la página a la que nos lleva esta opción: 235

238 Figura 49. Listado de jugadores sin clasificar (I) 236

239 Figura 50. Listado de jugadores sin clasificar (II) Por cada jugador listado, se presentan dos opciones: Modificar jugador: este enlace nos presenta la página que se muestra a continuación que permite modificar las características del jugador. Hay que tener en cuenta que la modificación en las características del jugador afectará a su clasificación por marcos así como a la generación de alineaciones. Borrar jugador: elimina el jugador de la base de datos 237

240 Figura 51. Modificar jugador El formulario permite modificar todos los parámetros visibles (salvo el nombre) y al pinchar en el botón submit, los cambios se almacenan en la base de datos y se vuelve a la página que muestra el listado de jugadores. 238

241 En la parte superior de la página del listado de jugadores, se nos muestran los siguientes enlaces: Figura 52. Menú de cabecera La opción añadir jugador presenta el siguiente formulario. Una vez relleno, el jugador es dado de alta en la base de datos y se vuelve a mostrar el listado de jugadores: 239

242 Figura 53. Alta manual de jugador La opción clasificar jugadores, permite lanzar el algoritmo de marcos que clasifica a los jugadores por demarcaciones teniendo en cuenta sus habilidades. Se puede observar que tras pinchar este enlace ya no aparece el texto en rojo sin clasificar, sino que aparecen las demarcaciones calculadas para cada jugador. 240

243 Figura 54. Listado de jugadores clasificados (I) 241

244 Figura 55. Listado de jugadores clasificados (II) Además, se puede observar que aparece un nuevo enlace consultar log clasificación. Si se pincha vamos a otra página que muestra el peso asignado por los marcos a ese jugador por cada demarcación, ordenado de mejor a peor demarcación. Se muestran un par de ejemplos a continuación. 242

245 Figura 56. Log de pesos de clasificación (I) Figura 57. Log de pesos de clasificación (II) 243

246 Si se echa la vista atrás unas capturas hacia atrás, se observa que queda un último enlace por pinchar: calcular alineación. Al pinchar el enlace, lo primero que se pregunta al usuario es qué algoritmo quiere utilizar. Figura 58. Selección de algoritmo de alineación 244

247 Independientemente de la opción que seleccione el usuario (el sistema anota la opción que ha seleccionado), se muestra la siguiente página para que el usuario seleccione el tipo de formación que desea utilizar: Figura 59. Selección del tipo de formación 245

248 La página explica las ventajas e inconvenientes de cada tipo de formación e insta al usuario a seleccionar una de ellas. Cuando el usuario selecciona un tipo de formación se le muestran páginas como las dos de ejemplo que vienen a continuación para que elija la disposición de los jugadores sobre el terreno de juego. Como se ha dicho, las capturas que se muestran a continuación son de ejemplo ya que hay 35 tipos de disposiciones de los jugadores en el campo para los siete tipos de formación seleccionables. Figura 60. Selección del tipo de formación (I) 246

249 Figura 61. Selección del tipo de formación (II) En este punto, el usuario debe pinchar sobre la imagen que se corresponda con la disposición de jugadores que mas le guste, lo que le llevará, ahora así a la página que muestra la mejor alineación posible según SEAH. A continuación se muestran un par de ejemplos, el primero utilizando el algoritmo estándar y el segundo el algoritmo de data mining, ambos para una formación utilizando la disposición de jugadores que aparecen en la primera imagen. 247

250 Figura 62. Alineación recomendada por el algoritmo estándar 248

251 Figura 63. Alineación recomendada por el algoritmo de data mining Además, aparece un enlace por cada jugador llamado log pesos alineación que permite consultar los marcos que calculados por cada algoritmo, en los que se puede observar ordenado de mayor a menor la posición ideal del jugador, la secundaria, la terciaria, etc. Se muestran un par de ejemplos. 249

252 Figura 64. Log de pesos de alineación (I) 250

253 Figura 65. Log de pesos de alineación (II) 251