Prototipo de simulación de creatividad computacional

PROTOTIPO DE SIMULACIÓN DE CREATIVIDAD COMPUTACIONAL DAVID LOSILLA CADENAS ROBERTO FERNÁNDEZ CORREA GRADO EN INGENIERÍA INFORMÁTICA FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID TRABAJO DE FIN DE GRADO CURSO 2018-2019 DIRECTOR: JUAN PAVÓN MESTRAS 2 A nuestros padres, hermanos y abuelos. 3 4 AGRADECIMIENTOS En primer lugar, nos gustaría dar las gracias a nuestro director, Juan Pavón Mestras, ya que este proyecto ha sido posible gracias a su ayuda y apoyo constante. Así mismo queremos agradecer a nuestra familia todo su apoyo y compresión, ya que siempre han estado cuando les hemos necesitado y nos han animado a seguir cuando el dia solo tenia 24 horas y teníamos que trabajar, asistir a la universidad y sacar adelante este proyecto. Por último nos gustaría dar las gracias al arquitecto Luis de Garrido, el cual ha aportando sus conocimientos sobre la materia y nos ha aportando la visión de un usuario final. 5 RESUMEN Este trabajo tiene como objetivo la ayuda al estudio de la creatividad humana. Se apoya en los estudios del arquitecto Luis de Garrido, el cual ha investigado una serie de cualidades que se encuentran presentes en las diferentes estructuras arquitectónicas. El cerebro humano, inconscientemente reconoce estas cualidades para determinar si una construcción es considerada “bella” o “adecuada”. Para ello se ha desarrollado un asistente creativo, el cual es capaz de generar diseños de estructuras arquitectónicas en base a una serie de condiciones, lo que puede ayudar en gran medida a expertos sobre la materia a estimular su creatividad y obtener una solución creativa. Para su implementación, se ha desarrollado una aplicación en Java, la cual es capaz de generar planos de estructuras en base a una serie de reglas e información proporcionada por el usuario. La creatividad de esta herramienta se basa en la combinación de reglas, por lo que está ligada directamente a la creatividad de estas. Se ha diseñado un mecanismo mediante el cual desarrolladores con conocimientos sobre arquitectura y creatividad puedan desarrollarlas de una manera sencilla, dedicando así sus esfuerzos en mejorar la creatividad de las mismas. Palabras clave Creatividad, reglas, plano, prototipo, desarrollo inteligente 6 SUMMARY This work aims to help the study of human creativity. It is based on the studies of the architect Luis de Garrido, who has investigated a series of qualities found in a different architectural structure. The human brain unconsciously recognizes these qualities to determine if construction is considered "beautiful" or "adequate." that is why a creative assistant has been developed, which is capable of generating architectural structure designs based on a series of conditions, which can greatly help experts on the subject, stimulate their creativity and obtain a creative solution. its implementation, an application has been developed in Java, powerful enough to generate structure drawings based on a series of boundaries and information provided by the user. The creativity of this tool is based on the combination of guidelines, so it is directly linked to their creativity. A mechanism has been designed where developers with knowledge about architecture and creativity can develop them in a simple way, thus dedicating their efforts to improve their creativity. Keywords Creativity, rules, plane, prototype, intelligent development 7 ÍNDICE AGRADECIMIENTOS 5 RESUMEN 6 SUMMARY 7 ÍNDICE 8 1. INTRODUCCIÓN 14 1.1. MOTIVACIÓN 14 1.2. OBJETIVOS 14 1.3. ESTRUCTURA DE LA MEMORIA 15 1.4. ESTADO DEL ARTE 16 1.INTRODUCTION 19 1.1. MOTIVATION 19 1.2.OBJECTIVES 19 1.3. MEMORY STRUCTURE 20 1.4. STATE OF THE ART 21 2. TECNOLOGÍAS EMPLEADAS 23 2.1. JAVA 23 2.2. SWING 23 2.3. GRAPHICS2D 24 2.4. BATIK APACHE 24 2.5. GIT 24 2.6. ECLIPSE 25 3. INTERACCIÓN CON EL USUARIO 26 3.1. PANTALLA INICIAL 26 3.2. MENÚS EJECUCIÓN 27 3.2.1 DISEÑO POR PASOS 27 3.2.2 DISEÑO COMPLETO 28 3.2.3 CARGAR DISEÑO 28 3.3. DATOS PARA LA EJECUCIÓN 29 3.3.1 NIVEL BÁSICO 30 3.3.2 NIVEL MEDIO 30 3.3.3 NIVEL AVANZADO 31 3.4. VENTANAS EJECUCIÓN 32 3.4.1 MODO PASO POR PASO 32 3.4.2 DISEÑO COMPLETO 39 8 3.5. PRODUCTO FINAL 40 4. EXPORTACIÓN DE RESULTADOS 46 4.1. EXPORTACIÓN DE PLANOS 46 4.2. EXPORTACIÓN DE ESTADOS DE LA EJECUCIÓN 48 5. ARQUITECTURA DE LA APLICACIÓN 50 5.1. ARQUITECTURA GLOBAL 50 5.2. ARQUITECTURA DE LA INTERFAZ 51 5.2.1. VENTANAS 51 5.2.2. CONTROLADOR 53 5.3. ARQUITECTURA DEL MOTOR DE REGLAS 54 5.3.1. REGLAS 54 5.3.2. MOTOR 56 5.4. ARQUITECTURA DEL MODELO 58 6. MOTOR DE REGLAS 60 6.1. INTRODUCCIÓN 60 6.2. FUNCIONAMIENTO GENERAL 61 6.3. RESOLVER ESTADO FINAL 62 6.4. EJECUCIÓN POR PASOS 63 6.5. CARGAR Y ERROR DE AVANCE 64 7. IMPLEMENTACIÓN 65 7.1. ESTADOS 67 7.2. FILTROS 68 7.3. REGLAS 70 7.4. MODELO 72 8. CONCLUSIONES 74 8. CONCLUSIONS 75 9. TRABAJO FUTURO 76 9. FUTURE WORK 78 10. DISTRIBUCIÓN DE ESFUERZO 80 10.1 INTERFAZ 80 10.2 MOTOR DE REGLAS 81 10.3 GENERADOR GRÁFICO 81 10.4 MODELO 81 11. APORTACIONES INDIVIDUALES 82 11.1. DAVID LOSILLA CADENAS 83 9 En el tercer apartado podemos encontrar una descripción de la interacción del usuario y la aplicación. En este punto podremos obtener una idea general del funcionamiento de la aplicación y que veremos como usuarios. En el cuarto apartado se detallan los procesos para poder exportar planos a formatos svg y png. También se detalla cómo se puede exportar un estado concreto de la ejecución para reanudarla más tarde. En el quinto apartado encontraremos un visión de la estructura del proyecto a un nivel más técnico, donde se podrá ver qué decisiones y arquitecturas se han tomado para el desarrollo. En el sexto apartado está explicado en mayor profundidad el funcionamiento y arquitectura del motor de reglas. En el séptimo apartado se explican las pautas para poder llevar a cabo una aplicación y así poder utilizarla para cualquier tipo de construcción. En el octavo apartado se pasan a detallar las conclusiones obtenidas durante el desarrollo de este proyecto. En el noveno apartado se encuentran las expectativas de trabajo futuro, con el cual se podría avanzar este proyecto y explotar su potencial. En el décimo punto se explica la distribución del esfuerzo empleado en el desarrollo del proyecto. En el undécimo punto se encuentran desglosadas las aportaciones individuales de cada uno de los participantes en este proyecto. Por último en el punto doce encontramos las instrucciones para el acceso y el uso del proyecto. 16 1.4. ESTADO DEL ARTE Actualmente no existe ninguna herramienta semejante o relacionada directamente, que hayamos conseguido encontrar. En lo referente al software relacionado con la arquitectura podríamos destacar Autocad. Autocad es uno de los programas más usados en el mundo de la arquitectura. Se trata de un software de pago que proporciona un gran abanico de herramientas para el diseño de planos en dos y tres dimensiones. Sin embargo, no tiene ninguna herramientas para la creación de planos automáticamente, todo tiene que ser diseñado por el usuario y la creatividad tiene que ser proporcionada por el mismo. Aunque Autocad no es capaz de crear planos automáticamente, si ofrece grandes características para su diseño, como pueden ser la capacidad de dibujo a mano alzada ya sea con el ratón o con un lápiz en dispositivos como tablets y Ipad, añadir anotaciones en las figuras diseñadas, o el cálculo de áreas, ángulos, radios... Durante los últimos años, en lo referente al proceso creativo han surgido grandes avances en este sector, gracias al auge de tecnologías como inteligencia artificial o machine learning, uno de los logros más famosos fue la creación del primer cuadro diseñado por un algoritmo. Actualmente hay diversos estudios que intentan fomentar la creatividad. Según estos estudios, hay diferentes tipos de creatividad. La creatividad plástica, es la que se relaciona con los colores, formas, volúmenes, texturas y proporciones, por tanto es la más ligada a la arquitectura. Se utilizan diferentes técnicas para fomentar la creatividad, las más relevantes son las siguientes. 17 ●Lluvia de ideas(brainstorm  ): las fases de este método son: planteamiento del problema, elección del grupo que realizará la lluvia de ideas y por último la evaluación de las ideas. La idea principal de esta técnica, es aprovechar las derivaciones de una idea general y así poder llegar a la resolución del problema. La aplicación, realiza algo parecido a un brainstorming ya que es capaz de aportar un gran número de planos (ideas), los cuales ayudan al usuario a encontrar la solución a su problema (diseño final) ● Estimulación por imágenes: Este proceso consiste en escoger un grupo de personas, y enseñarles una serie de imágenes, cada imagen deberá ser relacionada con la información del problema a resolver y de esta forma se intenta crear nuevas ideas. 18 1.INTRODUCTION In this section, we will proceed to explain the motivation of the project developed, its objectives and the state of the art. 1.1. MOTIVATION Creativity is the ability to generate new ideas or concepts, which usually produce original solutions. The main motivation of this project is the study and stimulation of human creativity, providing a large number of computationally solutions and the study of them, in order to achieve innovative designs or a series of specifications. A tool has been developed which attempts to simulate human creativity. 1.2.OBJECTIVES The main objective of the project is the development of a creative agent that is capable of generating creatively plans for any kind of structure. As a case of study, an application has been made on this to design basilicas and thus demonstrate its operation. These are the specific objectives: ● Development of an application that allows interactivity with the user and hashing different types of plans, taking into account the user's requirements. ● Possibility to export the designs to standard formats such as PNG and SVG so that they can be visualized with any image viewer or so, it also can be imported into tools such as Autocad, in order to work with them. 19 ● Development of a system that, although in this case has been used for the generation of basilica plans, can be used for the generation of any type of plans. 1.3. MEMORY STRUCTURE This report has the structure detailed below. In the first section, we can find a first approach to the work done, where we can find what has been the motivation, the objectives, the structure of the memory and the state of the art. In the second section, we will find an explanation of the main technologies that have been used during the development of this project. In the third section, we can find a description of the user’s interaction and the application. At this point we can get a general idea of the application's operation and what we will see as users. The fourth section details the processes to export plans to SVG and png formats. It also details how a specific state of execution can be detailed later. In the fifth section, we will find a vision project’s structure at a more technical level, where you can see what decisions and architectures have been taken for development. In the sixth section, the operation and architecture of the rule engine is explained in greater depth. The seventh section explains the guidelines to be able to carry out an application, therefore, be able to use it for any type of construction. In the eighth section, the conclusions obtained during the development of this project are detailed. 20 In the ninth section are the expectations of future work, so this project could be taken to the next level and exploit its potential. In the tenth point, the distribution of the effort used in the development of the project is explained. In the eleventh point, the individual contributions of each of the participants in this project are broken down. Finally, in section twelve we find the instructions for access and use of the project. 1.4. STATE OF THE ART Currently, there is no such tool we have managed to find. Regarding software related to architecture, we could highlight Autocad. Autocad is one of the most used programs in the world of architecture. It is a nonfree software that provides a wide range of tools for designing plans in two and three dimensions. However, it does not have any tools for creating plans automatically, everything has to be designed and provided by the user, so is creativity. Regarding the creative process, we have not found any software that attempts to emulate human creativity. There are currently several studies that try to encourage creativity. According to these studies, there are different types of creativity. The plastic creativity is the one that relates to colors, shapes, volumes, textures, and proportions, therefore it is the closest to architecture. There are some different techniques to increase creativity, these are some of the most relevant ones will be working with. 21 ●Brainstorm: The phases of this method are: problem statement, choice of the group that will brainstorm ideas and finally the evaluation of ideas. The main idea of this technique is to take advantage of the derivations of a general idea and thus be able to reach the resolution of the problem. The application performs something similar to a brainstorming since it is capable of providing a large number of plans (ideas), which help the user find the solution to his problem (final design) ●Image stimulation: This process consists of choosing a group of people, and showing them a series of images, each image must be related to the problem to be solved and in this way, we try to create new ideas. 22 2. TECNOLOGÍAS EMPLEADAS En esta sección se van a resumir las tecnologías utilizadas en el desarrollo del proyecto. 2.1. JAVA Java es un lenguaje de programación de propósito general, concurrente, orientado a objetos que fue diseñado específicamente para tener tan pocas dependencias de implementación como fuera posible. Java fue el lenguaje elegido debido a la facilidad que aporta la clase swing para crear interfaces de usuario, y la que aporta la clase graphics2D para el dibujo de los planos, además de ser el lenguaje de programación con el que más experiencia tienen los integrantes del proyecto. 2.2. SWING Swing es una biblioteca gráfica para java, con ella ha sido desarrollada la interfaz gráfica de la aplicación, la arquitectura Swing se basa en un Modelo-Vista-Controlador y su principal ventaja es la rapidez con la que permite crear interfaces de usuario. Existen diferentes alternativas a la hora de crear interfaces gráficas en Java, como por ejemplo SWT o Java FX. Se eligió utilizar Swing debido a la familiaridad con este y la numerosa documentación existente tras su largo recorrido. 23 2.3. GRAPHICS2D Esta es la clase fundamental para el renderizado 2D en Java. Esta clase extiende la clase original Graphics para proporcionar un control más sofisticado sobre la geometría, la transformación de coordenadas, la gestión del color y el diseño del texto. Graphics2D es la clase usada para el diseño de los planos, fue elegida debido a la rapidez en el renderizado de planos. 2.4. BATIK APACHE Batik es una librería de Java que permite obtener un archivo SVG o PNG a partir de un objeto de tipo Graphics2D. Debido a que la calidad de la imagen que ofrece la aplicación es muy baja se decidió transformarlo en SVG Y PNG, ya que los planos contienen pequeños detalles en los cuales es necesario ampliar bastante para que puedan ser observados, además, el formato SVG se puede importar en distintos entornos como Autocad para seguir trabajando con el plano. 2.5. GIT Es el sistema de control de versiones usado en el desarrollo del proyecto, permite trabajar en paralelo a todos los integrantes del equipo, la principal ventaja de Git frente a otros es su modelo de ramificación, ya que permite tener múltiples ramas independientes entre sí que más tarde pueden ser unidas. Además el plugin Egit aporta una fácil integración con eclipse. 24 2.6. ECLIPSE Eclipse ha sido el IDE utilizado para el desarrollo, las ventajas de este IDE son, un modo de depuración muy completo, autocompletado, resaltado de sintaxis y gran variedad de plugins que facilitan el desarrollo del proyecto. 25  3.4. VENTANAS EJECUCIÓN 3.4.1 MODO PASO POR PASO En esta ventana, como se ha mencionado anteriormente, se mostrará cada fase de la ejecución, donde se puede ir viendo el estado del plano. La creación de una basílica, está constituida por diferentes fases, cada una de estas fases contiene un conjunto de reglas aplicables, el sistema, teniendo en cuenta las respuestas del usuario a las preguntas, elegirá la regla más adecuada en cada caso. El usuario tendrá siempre la posibilidad de descartar los cambios realizados en cualquier fase, así como de guardar el estado actual o exportar los resultados a SVG o PNG. Figura 6: Ventana de ejecución en modo paso por paso 32  Figura 7: Botón que guarda el estado actual de la basílica El botón seleccionado es utilizado para guardar el estado actual de la basílica, será abierta una ventana de diálogo donde el usuario podrá elegir donde guardar el archivo y más tarde poder cargarla para seguir trabajando con ella. 33   Figura 8: Botón que permite exportar el diseño a PNG y SVG Este botón sirve para exportar el diseño actual en formato PNG o SVG, al igual que en el caso anterior, también se abrirá una ventana de diálogo donde el usuario podrá elegir la ubicación de destino en la cual serán guardados sus archivos. Figura 9: Botón que muestra los estados y reglas ejecutadas 34   Este botón se utiliza para mostrar los estados y la regla ejecutada en cada estado. Una vez pulsado el botón será mostrada al usuario la siguiente ventana. Figura 10: Ejemplo de fase y regla En este caso, se ha ejecutado la fase crucero, y en ella la regla “Crucero_3/4”, la cual ha creado un crucero con proporción ¾. Figura 11: Botón encargado de avanzar de fase o cambiar de regla 35   Con el boton rojo se cambia la regla utilizada en esa fase, y con el botón azul se ejecuta la siguiente fase. Si se pulsa el botón rojo, se aplica otra regla y por tanto se dibuja otro tipo de elemento o elementos arquitectónicos, en este caso será cambiado el crucero como se puede apreciar en el siguiente ejemplo. Figura 12: Ejemplo de cambio de regla Figura 13: Pantalla que muestra el cambio de regla 36  En este caso, como podemos observar se ha aplicado la regla “Crucero_2/3” en la fase crucero. Por otro lado, si hacemos click en el botón azul será ejecutada la siguiente fase. Figura 14: Imagen del modo de ejecución paso por paso Como se puede apreciar en la imágen superior, han sido ejecutadas las siguientes fases del plano pulsando el botón azul. El botón naranja situado en la esquina superior izquierda, da la posibilidad de retroceder a la fase anterior 37   Figura 15: Ejemplo de salto hacia la fase anterior 1 En esta imágen, podemos ver las fases y reglas ejecutadas en el plano antes de que el botón naranja sea pulsado. Figura 16: Ejemplo de salto hacia la fase anterior 2 38  Como se puede apreciar, al pulsar el botón, se ha vuelto a la fase anterior, ha desaparecido el cuerpo del patio de la basílica y actualmente está en la fase cuerpo de nave Figura 17: Ejemplo de salto hacia la fase anterior 3 Al ver nuevamente las fases y reglas aplicadas en ellas, se puede observar como la fase “Cuerpo_Patio” ha sido eliminada. 3.4.2 DISEÑO COMPLETO En este modo, después de responder a las preguntas, se generará un plano completo de la basílica. La ventana final se explicará más detenidamente en la siguiente sección. 39  3.5. PRODUCTO FINAL Una vez se hayan ejecutado todas las fases en el diseño por pasos, o se haya creado el plano de una basílica directamente como en el diseño completo, se mostrará la ventana con el plano final de la basílica. Figura 18: Plano final Una vez el usuario haya llegado a esta ventana, tendrá las opciones que se detallan a continuación. 40   Figura 19: Botón que guarda el estado actual de la basílica Como se ha mencionado anteriormente, este botón sirve para guardar el diseño. y poder seguir trabajando en él más tarde. Figura 20: Exportación del diseño en formato PNG o SVG Al igual que en el modo paso por paso, este botón permite exportar el diseño a los formatos PNG y SVG. 41 4.2. EXPORTACIÓN DE ESTADOS DE LA EJECUCIÓN La selección de un plano que se adecue a las necesidades del usuario es una tarea que puede llevar una gran cantidad de tiempo. Como se ha visto en otros puntos, en un plano se pueden modificar fases intermedias para poder ajustarlo a las necesidades requeridas. Esta herramienta cuenta con la posibilidad de exportar un estado concreto de la ejecución, ya sea un producto final o una fase intermedia. La funcionalidad de exportar el estado, otorga mucha flexibilidad al usuario, ya que tiene la posibilidad de guardar el punto en el que se encuentra para proseguir en otro momento sin perder todo su trabajo. También otorga la ventaja de poder guardar un diseño que no se adecua completamente pero que puede ser un gran candidato en otro momento. La exportación se realiza mediante la serialización de objetos Java, lo que permite extraerlos en archivos, los cuales hemos dotado de la extensión .edificio, para más tarde cargarlos y proseguir con la ejecución. En todas las ventanas donde visualizamos un estado concreto, a través del icono seleccionado, podemos iniciar la exportación. Este nos abrirá un diálogo, a través del cual podemos elegir la ubicación y el nombre del archivo que se van a generar. 48   Figura 30:  P  lano de la basílica Figura 31: Ventana de diálogo para la exportación del diseño 49  5. ARQUITECTURA DE LA APLICACIÓN 5.1. ARQUITECTURA GLOBAL La arquitectura de la herramienta está formada por un conjunto de componentes independientes entre sí. Podemos definir estos componentes como interfaz, motor de reglas, modelo y generador gráfico. ●Interfaz: este componente se encarga de interactuar con el usuario, es el encargado de recoger la información proporcionada por el usuario, así como, transmitir sus órdenes al resto de componentes de la herramienta. ● Motor de reglas: es el encargado de aplicar las diferentes reglas, dirigiendo la creación del plano en sus diferentes fases. ● Modelo: posee la definición de los objetos que constituyen el plano que se va a diseñar. Se encarga de implementar la representación de estos así como de determinar sus propiedades. ● Generador gráfico: la herramienta cuenta con un pequeño generador gráfico, el cual es capaz de generar salidas en diferentes formatos, permitiendo exportar los diferentes modelos generados. Figura 32: Diagrama  que muestra el hilo de ejecución de la aplicación 50  5.2. ARQUITECTURA DE LA INTERFAZ 5.2.1. VENTANAS Para la implementación de la interfaz uno de los aspectos más importantes es que sea lo más dinámica posible, evitando que sea necesario recargar ventanas o abrirlas y cerrarlas. Para la implementación de la interfaz se empleó SWING, buscando crear una interfaz lo más dinámica posible. Para conseguir este punto, se ha desarrollado una estructura de ventanas, mediante la cual solo se está visualizando una ventana (VentanaPrincipal), mientras que el resto de ventanas simplemente contienen los objetos que han de ser pintados. Figura 33: Diagrama de ventanas La ventana principal, posee definidas e identificadas, mediante un código, las ventanas secundarias. 51  Estas ventanas secundarias se encargan de definir los elementos SWING que van a ser visualizados, pero establece todos sus elementos en modo no visible y los mantiene identificados mediante claves en un mapa de elementos. La ventana principal se encargará de notificar a las ventanas secundarias si deben ser visibles o no, ordenando a todas que establezcan su modo no visible a excepción de la única ventana que ha de ser visible. Mediante este mecanismo conseguimos transiciones completamente fluidas entre ventanas, sin necesidad de cargar una ventana nueva y se proporciona un mecanismo para que desde otro punto de la aplicación, se pueda notificar qué ventana se debe mostrar de una manera sencilla.  Figura 34: Código de ventanas 52  5.2.2. CONTROLADOR En el apartado de la interfaz se encuentra definido un controlador denominado “ControladorEjecucion”. Este se encarga, como su nombre indica, de controlar la ejecución de la aplicación. Este objeto se crea usando el patrón de diseño singleton, por el cual solo existe una instancia en la aplicación. Todas las ventanas y el motor de reglas, poseen una referencia a él. Este se encarga de realizar la comunicación entre la interfaz y el motor de reglas, realizando las acciones necesarias indicadas por cualquiera de las partes. A través de este controlador, la interfaz es capaz de generar un motor de reglas y ordenar un tipo concreto de ejecución, enviando al motor de reglas todos los datos necesarios para su ejecución, así como, la información introducida por el usuario. Como se verá en el siguiente apartado, el motor de reglas actúa en un hilo de ejecución independiente. El controlador de ejecución, será el encargado de crearlo, comunicarse con él y finalizarlo de manera correcta. Figura 35: Esquema controlador 53 5.3. ARQUITECTURA DEL MOTOR DE REGLAS La herramienta cuenta con un motor de reglas propio, inicialmente, se planteó la idea de utilizar un motor ya existente, como por ejemplo Drools. Existen varias opciones como Drools o Jess, las cuales tienen un gran recorrido y documentación, siendo herramientas muy maduras. El problema que se encontró con estas herramientas, fue que no conseguimos encontrar una forma mediante la cual reutilizar gran parte del código para futuras aplicaciones a estructuras. Por esto se decidió implementar un motor de reglas propio, el cual estuviese especializado en el proyecto y que permitiese reutilizar la mayor parte posible de una aplicación a otra. Se puede dividir el motor en dos partes, las reglas y el motor en sí mismo. 5.3.1. REGLAS Se ha diseñado una estructura de reglas basada en una interfaz, ReglaBase, la cual intenta acumular todo el trabajo posible común a todas las reglas, para que así se necesario programar una pequeña parte a la hora de diseñar una regla y que la mayor parte del tiempo sea invertido en la creatividad de la misma. Cada regla, está constituida por una serie de atributos, los cuales podemos identificar como: ●Predicados edificio: lista de predicados referentes al edificio, los cuales se encargaran de validar si la regla puede ser aplicada o no, en función del estado en el que se encuentra el edificio sobre el que se va a aplicar. ●Predicados usuario: lista de predicados referentes a los datos introducidos por el usuario, los cuales se encargan de determinar 54 si la regla generaría un resultado que se ajustase a los requerimientos de este. ●Estado: determina en qué fase de la ejecución deberá ser aplicada esta regla. ●Código: código que permite identificar a las reglas durante la ejecución, para más tarde poder conocer qué reglas son responsables del producto final. Cada regla tiene una serie de métodos, los cuales permiten desarrollar diferentes acciones: ● InicializarEstadosPredicados: este método se encarga de definir cuáles serán los predicados concretos de la regla, así como, determinar a qué estado pertenece. Este método debe ser implementado por las reglas que sean creadas. ● Test: este método se encarga de validar las diferentes listas de predicados, para así determinar si la regla puede ser aplicada o debe ser descartada. Este método no es necesario que sea implementado, recupera los predicados que fueron creados por “inicializarEstadosPredicados”; ● AplicarRegla: este método se encarga de llevar a cabo las modificaciones sobre el edificio que se le ha proporcionado. Este método debe ser implementado al crear una nueva regla. ● Copiar: este método se encarga, mediante serialización, de generar una copia del edificio proporcionado, para que las modificaciones no afecten en caso de descartar la regla (se verá en detalle en la explicación del motor). No debe ser implementada. ●Execute: este método se encarga de controlar todo el proceso de la regla. Primero comprueba mediante el método test si esta puede ser aplicada o no, para después aplicar la regla mediante 55  “aplicarRegla” devolviendo el resultado obtenido. No debe ser implementado. ● Constructora: se debe crear una constructora del objeto, en la cual se define el código de la regla y se llama a la constructora de “ReglaBase”, la cual se encargará de llamar a “inicializarEstadoPredicados”. ● GetCodigo: permite acceder al código de la regla. No debe ser implementado. ● GetEstado: permite acceder al estado al cual está asociado la regla. No debe ser implementado. Figura 36: Ejemplo código de reglas 56 5.3.2. MOTOR El motor es el encargado de controlar toda la ejecución de las reglas. Este se encuentra definido en la clase “ControladorReglas”. Este es independiente de la aplicación, es capaz de trabajar con cualquier conjunto de reglas que extiendan de la clase “ReglaBase” y cualquier representación que extienda de la clase “Edificio”. Está implementado como un hilo de ejecución independiente. Este será creado y arrancado por la aplicación y se mantendrán en continua comunicación, intercambiando información y órdenes entre ellos. Para el intercambio de información se intentó usar señales, pero tras leer documentación y realizar pruebas, se observó que muchas de ellas estaban deprecadas y su funcionamiento no era del todo fiable. En base a esto se buscó documentación para desarrollar un sistema con el cual poder intercambiar órdenes correctamente y controlar tiempos de espera o finalización. Para ello se implementó un mecanismo de espera de parámetros, de tal forma que uno de los dos extremos, se puede mantener a la espera de recibir una orden a través de la consulta periódica de una variable. Se entrará más en profundidad acerca de la comunicación y el funcionamiento del algoritmo implementado en forma de árbol de decisión en el siguiente punto (6. MOTOR DE REGLAS) 57  6.5. CARGAR Y ERROR DE AVANCE En el caso de realizar una carga, que haya sido exportada previamente, se arrancará el motor de reglas indicando que se trata de una carga. Este recibirá de que tipo de ejecución se trataba, los datos de usuario que estaban introducidos en el momento de la exportación, así como que regla fué ejecutada en cada estado. Este comprobará en cada estado si posee una regla que fue ejecutada en el, en caso afirmativo la ejecutará y saltará al siguiente estado. En caso de que no exista una regla que fue ejecutada en ese estado indica que a partir de ese punto a finalizado la carga y debe continuar de manera normal. Puede darse el caso, que debido a la configuración introducida por el usuario o al excesivo descarte, se llegue a un punto en el que sea inviable continuar la ejecución por falta de reglas que se puedan ejecutar en alguno de los estados. LLegados a este punto el motor detectara que hay un error de avance y finalizará su ejecución informando al usuario de que no existían combinaciones posibles, por lo que el usuario debe modificar los filtros que ha introducido. Figura 43: Imágen cargar error 64  7. IMPLEMENTACIÓN Uno de los principales objetivos de este proyecto, es diseñar una herramienta con la cual fuese posible desarrollar distintos tipos de plano. En este caso se ha desarrollado una aplicación para desarrollar planos de basílicas, pero podría ser empleada para desarrollar el diseño de planos de otro tipo de estructura arquitectónica.. En la estructura del proyecto, encontramos que se encuentra dividida en dos paquetes, “implementacion” y “agente_creativo”. El paquete implementación contiene el modelo y las reglas específicas para crear el diseño del plano, en este caso para el diseño de basílicas cristianas. Si se quiere diseñar otro tipo de plano, sería necesario crear el modelo de la estructura arquitectónica a diseñar, sus estados y sus reglas, por tanto, todos los fuentes que deben ser modificados para la creación de otro plano se encuentran en “implementacion”. El paquete “agente_creativo” contiene el resto del código de la aplicación, interfaz, motor de reglas y generador gráfico. Figura 44: Paquete implementación 65 A continuación se van a enumerar y explicar los cambios que serían necesarios para poder llevar a cabo un elemento arquitectónico diferente de la basílica cristiana. 66  7.1. ESTADOS Para el correcto desarrollo de la ejecución, están definidos una serie de estados o fases, gracias a los cuales se establecen las diferentes fases en las que se construye un edificio. Las reglas que se ejecutarán están asociadas a un estado concreto para así determinar en qué momento de la ejecución han de utilizarse. A la hora de realizar una nueva aplicación, se deben reemplazar estos estados por los de la propia aplicación. Los únicos estados que se deben mantener obligatoriamente en las posiciones que se encuentran son “FINALIZAR_EJECUCION”, “ERROR_AVANCE”, “TERMINADA” y “RELANZAR”, ya que estos estados son usados internamente para detectar determinadas circunstancias. No existe ningún límite de estados, se pueden definir tantos como se consideren oportunos o sean necesarios, siempre y cuando se respete el punto anterior. Figura 45: Código de estados 67  7.2. FILTROS Uno de los puntos claves del proyecto es el descubrimiento de los requisitos o gustos del usuario. Para recabar información acerca de estos, se realizan una serie de preguntas al usuario, las cuales determinan las decisiones que se tomarán a la hora de aplicar las reglas y desarrollar las fases de la ejecución. La definición de estas preguntas se encuentra en la clase “ControladorPreguntas.java”. En este podemos encontrar diferentes Map en los cuales se encuentran definidas, mediante clave - valor, las diferentes preguntas. ●preguntasSimples: se trata del mapa que aloja las preguntas del apartado medio. Es necesario rellenar este mapa con las preguntas y respuestas que se desean realizar en el método “cargarPreguntas”. Figura 46: Código de preguntas simples ●preguntasComplejas: se trata del mapa que aloja las preguntas del apartado avanzado. Es necesario rellenar este mapa con las preguntas y respuestas que se desean realizar en el método “cargarPreguntas”. 68   Figura 47: Código de preguntas complejas ● preguntasInteligentes y estadosInteligentes: se trata del mapa que aloja las preguntas del apartado mejora inteligente. En este caso “preguntasInteligentes” contiene las preguntas y respuestas de este apartado, mientras que “estadosInteligentes”, contiene el estado asociado a cada respuesta, para así determinar que parte de la ejecución es válida y cual no se ajusta a los requerimientos del usuario. Es necesario rellenar este mapa con las preguntas y respuestas que se desean realizar en el método “cargarPreguntas”. Figura 48: Código de preguntas inteligentes 69  7.3. REGLAS Todas las reglas, tienen que extender de la clase abstracta ReglaBase e implementar los métodos “inicializarEstadoPredicados” y “aplicarRegla”. El método inicializarEstadoPredicados implementado en cada regla, tiene en cuenta las respuestas introducidas por el usuario y la composición actual del edificio, será el encargado de decidir si la regla se puede ejecutar o no. El método aplicarRegla  creará los elementos arquitectónicos necesarios en dicha regla. Figura 49: Código de la clase ReglaBase A continuación se procede a explicar cómo está estructurado el ejemplo que encontrará el usuario, a modo de guia. 70   Para una mejor organización, debido a la relación entre los estados y las reglas, se decidió crear un paquete por cada estado y este contendrá todas las reglas aplicables al estado al que hace referencia dicho paquete. Para una mejor reutilización de código, cada paquete contiene una regla abstracta encargada de implementar los métodos inicializarEstadoPredicados yaplicarRegla. Por tanto las demás reglas, sólo tienen que extender la regla abstracta mencionada anteriormente inicializando sus atributos según sea conveniente en cada regla. Figura 50: Paquete reglas En las siguientes imágenes se muestra un ejemplo con las reglas del estado Capillas. Figura 51: Código de   reglas 71  7.4. MODELO A continuación se procede a explicar cómo está estructurado el ejemplo de modelo que encontrará el usuario, a modo de guia. Como se ha mencionado anteriormente, la arquitectura del modelo está dividida en niveles. Figura 52: Código de la clase Nivel 2 Cada nivel, tiene una lista de elementos del nivel posterior. Los elementos pertenecientes a los niveles superiores, son elementos generales que están formados por la unión de elementos del siguiente nivel. Se continúa con esta premisa, hasta llegar al último nivel, en el cual los objetos pertenecientes a este nivel, son lo suficientemente simples como para poder dibujarse directamente. Los elementos del último nivel son dibujados utilizando los objetos proporcionados por la clase Graphics2D 72   Figura 53: Elementos concretos Por ejemplo, el objeto de nivel 2 “CuerpoNave” está compuesto entre otros. por la unión de los objetos Nave, pertenecientes al nivel 3 y estas a su vez están compuestas por muros, columnas…, estos últimos objetos pertenecen al nivel 4, por tanto sólo contienen los objetos de la clase Graphics2D necesarios para ser dibujados, como se ve en el ejemplo del objeto columna en la siguiente imagen. Figura 54: Código de la clase Columna 73  10. DISTRIBUCIÓN DE ESFUERZO Figura 55: Distribución del esfuerzo 10.1 INTERFAZ Fue invertido mucho tiempo en el estudio de la biblioteca gráfica swing, con la cual se diseñó la interfaz. Gran parte del tiempo fue invertido en la búsqueda de un mecanismo para aportar la mayor fluidez posible a la interacción con el usuario. Se probaron varias opciones hasta alcanzar una arquitectura con la que el grado de fluidez de la interacción era el deseado. 80 10.2 MOTOR DE REGLAS La mayor parte del tiempo, fue invertido en el diseño del algoritmo encargado de llevar a cabo las fases y la ejecución de las reglas. Además de ello, cabe destacar el tiempo invertido en controlar la ejecución de este algoritmo en un hilo de ejecución separado. 10.3 GENERADOR GRÁFICO Como muestra el diagrama, en el generador gráfico fue donde menos tiempo fue invertido. Para su creación fue necesario el aprendizaje de la librería BATIK la cual permite, a partir de un objeto Graphics2D crear una imagen de tipo SVG y PNG. 10.4 MODELO Una gran parte del esfuerzo, fue destinado al desarrollo del modelo, debido a nuestros escasos conocimientos de arquitectura y más concretamente sobre basílicas. Antes y durante el desarrollo del modelo, tuvimos que adquirir muchos conocimientos sobre cómo se crean los elementos arquitectónicos, como se unen entre sí, sus dimensiones, proporción… Además cabe mencionar el tiempo invertido en el estudio de la librería Graphics2D con la cual se dibujan los planos. 81 11. APORTACIONES INDIVIDUALES En el desarrollo de este proyecto, el peso del trabajo ha sido repartido de forma equitativa, ambos integrantes del equipo han trabajado en todas las partes del proyecto. Desde un principio se han definido una serie de iteraciones con unos objetivos marcados, distribuyendo las tareas en entre ambos participantes y realizando rectificaciones en estas cuando alguna tarea era más compleja de lo esperado. Aun así, cada uno de los integrantes a aportado un poco más de peso en alguna de las partes del proyecto. Para llevar a cabo una valoración del trabajo, se va a dividir el proyecto en cuatro partes: motor de reglas, interfaz, modelo y creación de reglas, indicando simplemente en que partes ha existido una mayor contribución de un integrante. 82  11.1. DAVID LOSILLA CADENAS Como resumen de la contribución del integrante David Losilla, podemos destacar el desarrollo del motor de reglas, diseñado su estructura para definir su comportamiento. También podemos destacar el diseño de la arquitectura de la interfaz, estableciendo el flujo de ventanas, la interacción con el usuario y la comunicación con el resto de componentes de la herramienta. Por último podríamos destacar, el diseño de interfaces para buscar la menor dependencia entre aplicaciones, para un posible trabajo futuro sobre el proyecto. Figura 56: Diagrama de trabajo individual David Losilla 83  11.2. ROBERTO FERNÁNDEZ CORREA Como resumen de la contribución del integrante Roberto Fernández, se puede mencionar la creación de la arquitectura de las reglas y del modelo. Además cabe destacar el estudio de la clase Graphics2D usada para dibujar los elementos arquitectónicos de la basílica y el estudio de la librería Batik, que permite exportar el diseño creado con Graphics2D a formatos estándar como SVG y PNG. Figura 57: Diagrama de trabajo individual Roberto Fernández 84 12. ACCESO Y USO DEL PROYECTO Este proyecto ha sido desarrollado como una herramienta de código abierto. Se invita a cualquier persona que lo desee, a realizar sus propias aplicaciones o introducir las mejoras que pueda aportar al proyecto. El único requisito que se solicita, es que se compartan los desarrollos realizados sobre este. Todas las mejoras o aplicaciones han de ser subidas al repositorio para entre todos conseguir una herramienta gratuita de calidad. Este proyecto se encuentra en github, alojado como un repositorio público en la siguiente dirección: https://github.com/PROTOTIPO-SIMULACION-CREATIVIDAD/PROTOTIPO 85 12. ACCESS AND USE OF THE PROJECT This project has been developed as an open-source tool. Any person who wishes to do so is invited to make their own applications or introduce the improvements they can bring to the project. The only requirement that is requested is that the developments made on it be shared. All improvements or applications have to be uploaded to the repository to get a free quality tool together. This project is in GitHub, hosted as a public repository at the following address: https://github.com/PROTOTIPO-SIMULACION-CREATIVIDAD/PROTOTIPO 86 BIBLIOGRAFÍA ● Manual GIT https://git-scm.com ● Manual Java 8 https://www.java.com ● Batik SVG https://xmlgraphics.apache.org/batik/using/svg-generator.html ● Api de Graphics2D https://docs.oracle.com/javase/7/docs/api/java/awt/Graphics2D.html ●Java swing https://docs.oracle.com/javase/7/docs/api/javax/swing/package-summary .html ●Serialización de objetos https://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html ●Documentacion de Autocad https://www.autodesk.es/products/autocad/overview https://latinoamerica.autodesk.com/products/autocad-360/features/all ● Diferentes artículos que investigan la creatividad humana https://elcultural.com/Los-origenes-de-la-creatividad-humana https://es.wikipedia.org/wiki/Creatividad https://www.neuronilla.com/tecnicas-de-creatividad-carlos-churba/ https://programas.cuaed.unam.mx/repositorio/moodle/pluginfile.php/166/ mod_resource/content/1/la-creatividad/index.html https://www.xataka.com/robotica-e-ia/sale-a-subasta-primera-vez-obra-ar te-generada-algoritmo 87