Propuesta de Oferta general para Proyecto Fin de Carrera (tipo A) en el Departamento de IA para el curso 2013-14 11 de octubre de 2013 1. Datos de identificación del Proyecto de Fin de Carrera Tipo: Oferta genérica (tipo A). Departamento: Inteligencia Artificial. Curso: 2013-14. Título: Desarrollos flexibles de GUIs mediante técnicas de Ingeniería del Software. Directores: José Manuel Cuadra Troncoso jmcuadra@dia.uned.es y José Luis Aznarte Mellado jlaznarte@dia.uned.es. Requisitos: Programación orientada a objetos en Java, programación de interfaces gráficas de usuario con Swing. 2. Descripción del problema a resolver 2.1. Origen y motivación CyBeRSim es un software orientado a la simulación y el control de conductas en robots autónomos en desarrollo en este departamento, está escrito en C++, usa la librería gráfica Qt-4 de Nokia y su software de diseño de GUIs QtDesigner. Durante una fase del desarrollo se llegó a la conclusión de que era necesario diseñar una biblioteca que permitiera la reusabilidad de las interfaces gráficas (GUIs). Esta necesidad surgió en dos escenarios distintos, que pueden aparecer mezclados. El primero era cómo crear una jerarquía de interfaces gráficas, generalmente diseñados con un diseñador gráfico, para editar una jerarquía de clases de manera que no se duplicara código ni componentes gráficos (widgets). El segundo cómo integrar interfaces gráficas de objetos asociados en una GUI general, pero conservando la posibilidad de mostrar cada 1
cuadro individual cuando fuera necesario, de nuevo sin duplicación de código ni de componentes gráficos. Además el proceso debería ser transparente para usuarios y programadores, tanto los que diseñan las GUIs como los que las usan al programar aplicaciones. Precisaremos lo que se quiere decir con transparencia más adelante, ahora vamos a comentar un ejemplo de cada escenario. Para entender mejor los tamaños de las figuras diremos: que todas están escaladas, con el mismo factor de escala, con respecto a como se muestran en pantalla; a las GUIs cuando se les acaba de diseñar se les da el tamaño mínimo aconsejable según la distribución (layout) dada a sus componentes; las GUIs creadas en tiempo de ejecución se muestran en pantalla, redimensionándose quizás, en función del tamaño del mayor de las GUIs integradas. Hablaremos de la distribución de componentes más adelante. Ejemplo 1: jerarquía de GUIs asociada a una jerarquía de clases. CyBeRSim dispone de un editor de redes neuronales. Estas redes pueden contener clases de una jerarquía de neuronas. La clase base se edita mediante la GUI de la figura 1, diseñada como todas las demás con Qtdesigner. Una determinada clase derivada sólo tiene un campo más a editar por lo que se diseña la GUI de la figura 2. El programador de aplicaciones con unas pocas líneas instancia la GUI de la clase base, la de la clase derivada y las ensambla en una GUI completa con botones 1, ver figura 3. Otra clase derivada tiene una gran cantidad de campos que editar, ver figura 4, de manera que al integrarla con la GUI de la clase base es mejor crearla en una pestaña aparte, ver figura 5. Figura 1: GUI asociada a la clase base Figura 2: GUI de campos exclusivos de clase derivada 1 El hecho de que los diálogos con botones aparezcan traducidos al castellano al uso del sistema de internacionalización de Qt, no es parte de los requisitos de este proyecto, de hecho es el diseñador de GUIs el que debe lidiar con la internacionalización. 2
Figura 3: GUI completa asociada a la clase derivada obtenida por integración en tiempo de ejecución de los GUIs de las figuras 1 y 2 Figura 4: GUI exclusiva asociada a otra clase derivada con gran cantidad de campos 3
(a) (b) Figura 5: GUI completa, creada en tiempo de ejecución, integrado por las GUIs de las figuras 1 y 4. a) Página correspondiente a la clase base, la GUI de la figura 1 se redimensiona adecuadamente según tamaño del de la figura 4, que es la mayor de las dos. b) Página correspondiente a la clase derivada, ver figura 4. 4
Figura 6: GUI asociada a la clase base de la jerarquía de simulaciones, esta clase base no tiene asociados robots. Ejemplo 2: integración de GUIs de objetos asociados Un objeto de la jerarquía de simulaciones en CyBeRSim tiene muchos objetos asociados. Como objetos de la jerarquía de robots, objetos de la jerarquía de controladores de robots, objetos de las jerarquías de monitores de actividades, etc. Al editar los parámetros de la simulación y sus objetos asociados resulta más cómodo para el usuario tener todos las GUIs en una sólo y no tener que ir buscando por el sistema de menús dichas GUIs. De esta manera también se pueden editar conjuntamente campos de GUIs distintas, implementando un sistema de paso de mensajes entre ellas. En las figura 6 a 8 se pueden observar páginas individuales e integradas de la GUI de un objeto de la clase simulación. La GUI de la figura 6 se diseñó con botones incluidos, ya que se consideró que siempre que se muestre será una GUI de nivel superior, o sea no contenida en otra, y con vista de árbol. Esta GUI se podría haber diseñado sin botones y sería tarea del programador de aplicaciones envolverlo en una GUI con la vista de árbol y los botones, como en el ejemplo 1. En este caso la navegación por las distintas páginas de la GUI se realiza mediante una vista de árbol situada en la región izquierda de la GUI, ver figura 8. Se decidió implementar la navegación de esta manera pues esta GUI contiene varios niveles de anidamiento, no se emplearon pestañas pues su anidación dificulta la localización de las GUIs y reduce el tamaño útil de la ventana. En la figura 9 se muestra una GUI con botones con dos pestañas en una de ellas se inserta la GUI de la figura 7 y, en la otra, parte de la GUI correspondiente a la clase base del objeto editado. La GUI asociada a la clase base no muestra en las figuras, pero puede verse la referencia a dicha GUI en la lista de la vista de árbol de la figura 8, este es un ejemplo de inserción de listas de GUIs relacionadas. El programador de aplicaciones ensambló la GUI de la figura 9 porque esta es la parte la GUI de la figura 8 más utilizada por el usuario, para mayor comodidad se accede a él mediante un simple clic sobre la imagen del robot, a la GUI general, figura 8, se accede desde el menú principal de la aplicación. Estos ejemplos pueden dar una idea de la conveniencia de disponer de GUIs reusables. 5
Figura 7: Cuadro de diálogo, de campos exclusivos, de una clase derivada de la jerarquía de robots. 2.2. Requisitos Para buscar una solución al problema expuesto en la sección 2.1 primero deberemos precisar los requisitos. 1. Los tipos de GUIs, ya comentados en los ejemplos, serán los siguientes: a) GUIs de una sola página, que denominaremos simples, en las que se integran como máximo dos GUIs 2. b) GUIs con navegación mediante pestañas. c) GUIs con navegación mediante vista de árbol. 2. Cualquier tipo de GUI se debe poder anidar cualquier otro, aunque ciertas combinaciones no tengan mucho sentido. El nivel de anidamiento de GUIs, salvo para la simple, debe ser teóricamente ilimitado. 3. El proceso debe ser transparente para: a) El usuario. La edición de una GUI debe ser considerada como una transacción atómica, por lo que lo editado en cada una de su páginas debe ser aceptado o rechazado con una sola acción, una sola pulsación de botón del usuario al finalizar la edición completa. b) El diseñador de GUIs. Debe poder tratar estas GUIs como las normales de la librería gráfica que se use, salvo, quizás, algunos pocos métodos añadidos para la reutilización y teniendo en cuenta que si existe un mecanismo previo de extensión de GUIs en la librería gráfica debería ser explícitamente anulado para que no entre en conflicto el mecanismo de reusabilidad aquí expuesto. c) El programador de aplicaciones. Sólo debe tener acceso a la interfaz pública de la jerarquía de GUIs reusables, que, además de la propia de las GUIs normales de la 2 Se tomó este valor máximo para estar seguros de que la GUI no se saldría de la pantalla 6
(a) (b) Figura 8: GUI, creada en tiempo de ejecución, asociada a una clase derivada de la jerarquía de simulaciones que sí tiene asociados robots. En la izquierda de las ventanas puede verse la vista de árbol usada para navegar por las GUIs, tiene tres niveles de anidación. En a) se muestra la GUI de la figura 6 y en b) la de la figura 7. Las GUIs de la figuras 6 y 7 se redimensionan adecuadamente al tamaño de la mayor GUI anidada, no mostrada en estas figuras. 7
Figura 9: GUI completa, creada en tiempo de ejecución, asociada a una clase derivada de la jerarquía de robots, mostrando una de sus páginas, ver figura 7. Las dos páginas de esta GUI también están accesibles desde el diálogo de la figura 8. librería gráfica, debe constar de métodos para añadir GUIs, listas de GUIs relacionadas y para la inicialización propia de los GUIs reusables, aparte de la que puedan tener como GUIs normales. Además debe contar un procedimiento sencillo para el ensamblado de basado en métodos polimórficos, de manera que cada clase a editar pueda ensamblar convenientemente su propio GUI reusable, ya sea por invocación del los mismos métodos en las clases de niveles más básicos de su jerarquía y/o por invocación de métodos con igual propósito en los objetos asociados. 4. Se debe mantener en lo posible la estética de las GUIs diseñadss. Esto tiene que ver principalmente con el redimensionamiento de ventanas, ya sea por necesidades propias de la integración de GUIs y/o por acciones del usuario. Esta cuestión se resuelve mediante la distribución (layout) de los componentes gráficos que forman la GUI. Esta distribución no es una mera colocación sino también un procedimiento de recolocación y redimensionamiento, bastante sofisticado, que poseen los componentes gráficos, especialmente los diseñados para ser contenedores de componentes, en realidad una distribución es un objeto asociado al componente. El requisito estético se concreta en que se debe diseñar el proceso de reutilización de manera que se preserven las distribuciones al integrar GUIs pero sin que se acumulen los márgenes externos de las GUIs al anidar, ya que eso va reduciendo el espacio útil de la ventana. 5. Debe existir un mecanismo para crear GUIs de los tres tipos requeridos en el punto 1, con la estructura mínima: botones para aceptar la edición y rechazarla, contenedor apropiado con distribución y vista de árbol para el último de los tipos requeridos. Estas GUIs las usa el programador de aplicaciones para envolver GUIs sin botones. Es preferible que se diseñen las GUIs sin botones, salvo excepciones como la de la figura 6, para no tener el problema de qué hacer con ellos al integrar GUIs. 6. Comunicación entre GUIs integradas, hay que arbitrar un sistema de paso de mensajes entre GUIs. 8
7. Deseamos proteger lo más posible el funcionamiento interno de las clases de la biblioteca, nueva referencia a una interfaz pública reducida, y poder forzar al diseñador de GUIs la implementación de ciertos métodos, imprescindibles para el funcionamiento del proceso a implementar, de manera que su ausencia sea detectada en tiempo de compilación. 8. Se usará polimorfismo en lugar de reflexión, introspección sobre clases, siempre que sea posible. En la implementación en C++ se usó la introspección, cuando no se pudo hacer de otra forma, que proporciona la librería Qt. 9. Se debe poder diseñar las GUIs reusables en un editor gráfico de GUIs, tal y como se diseñan los GUIs usuales. Esto es una parte de la transparencia requerida para el diseñador de GUIs, pero la separamos aparte por que añade complejidad extra al diseño del proceso de reutilización. De hecho el patrón exacto que describiremos como solución del problema de la reusabilidad es posible que no pueda ser implementado para ciertos diseñadores gráficos, o tenga una solución muy compleja, el problema proviene de la última parte del requisito 4. En el caso de la implementación en C++ hubo suerte con el diseñador, pero fue necesario conocer al detalle su funcionamiento para encontrar el modo de implementar el patrón de forma exacta. Si el alumno, investigando el funcionamiento del editor gráfico, llega a la conclusión de que no es posible la implementación exacta, debe ofrecer un razonamiento que apoye dicha conclusión e implementar una solución de compromiso. 10. La implementación del proyecto se estructurará un forma de biblioteca de clases, usando el lenguaje de programación Java y la librería gráfica Swing. La biblioteca se empaquetará en un archivo de tipo jar. 11. Se debe elaborar un programa de prueba, según el siguiente esquema mínimo: a) Los campos (variable) en una clase no tendrán acceso público, sino a través de métodos accesores, este es un requisito general para todo el proyecto. b) Crear una clase, p. ej. A, con al menos cinco campos. Derivar de A dos clases, A1 y A2. A1 añade uno o dos campos más a la clase base. A2 añade al menos cinco. c) Diseñar GUIs reusables para editar todos los campos de las clases A, A1 y A2. Diseñarlas sin botones, para que posteriormente sean envueltas en GUIs reusables con estructura mínima, y darles una distribución adecuada. Usar cierta variedad de componentes gráficos en las GUIs. d) Crear tres clases B, C, D con al menos cinco campos cada una y de manera un objeto de clase A1, otro de clase A2 y otro de clase C estén agregados en uno de clase B, y uno de clase D esté agregado en uno de clase C. e) Diseñar GUIs reusables para editar los campos de las clases B, C y D. El de B debe contener vista de árbol y botones, los otros no, darles una distribución adecuada. Usar cierta variedad de componentes gráficos en las GUis. Mediante la comunicación de GUIs requerida en el punto 6, el cambio en un determinado componente gráfico de la GUI de D debe provocar un cambio en uno de B, p. ej. al deslizar un JSlider en la GUI de D que cambie un número en un JSpinner en la de B. 9
f ) Crear un aplicación con interfaz gráfica en la que se vayan mostrando, y se puedan editar, las GUIs completas de A1, en una sola página (simple), de A2, con pestañas, y de B, con vista de árbol en la que se pueda acceder a todos las GUIs de sus objetos agregados y los agregados a sus agregados. Las GUIs deben ser ensambladas siguiendo el procedimiento a desarrollar comentado en el requisito 3(c). La edición debe ser real, o sea, con actualización de campos en los objetos al aceptar la edición el usuario, previa validación de la coherencia de los datos. g) Las GUIs ensamblados deben tener un buen comportamiento frente a redimensionamientos realizados por el usuario. 12. El proyecto debe estar debidamente documentado usando un sistema estándar de documentación, como pueden ser Javadoc o Doxygen. 13. El software producido debe ser de código abierto, bajo la licencia GPL. Se recomienda al alumno usar la convención de nombres estándar de Java, ver sección 4. 2.3. Patrones de diseño y otras técnicas de la programación orientada a objetos En esta sección se van a exponer o comentar patrones de diseño y otras técnicas de la programación orientada a objetos que proporcionan una solución al problema planteado que cumple los requisitos 1 a 8, salvo la parte final de 3(c). Para el requisito 9, al menos la solución de compromiso, se dispone de la tecnología JavaBeans. El requisito 10 está claro, en la sección 4 se darán referencias a textos sobre Java, sobre patrones y herramientas de programación. El requisito 11 está claro, salvo en (f) relacionado con final de 3(c), para el que es necesario un nuevo patrón muy simple, cuyo desarrollo se deja al alumno. Los requisitos 12 y 13 están claros. 2.3.1. El patrón de reusabilidad Describimos el patrón que proporciona reusabilidad a las GUIs, realmente es un conjunto de patrones y otras técnicas de la programación orientada a objetos. Las GUIs reusables pueden derivar de la clase básica de diálogos de la biblioteca gráfica que se use, así dispondremos de toda la funcionalidad de dicha clase y, además, el proceso irá cumpliendo los requisitos de transparencia pedidos. Derivarlos de clases más básicas de la jerarquía puede ofrecer más flexibilidad a costa de mayor complejidad. Las GUIs reusables se deben diseñar según el patrón objeto compuesto (composite): una jerarquía de clases en la que cada objeto tiene una lista de objetos hijos derivados de su misma clase base que actúan polimórficamente. Esto permite construir, de forma recursiva, objetos complejos a partir de otros más sencillos con los que comparte una interfaz común, requisito 2. Conviene crear una clase base, la que ofrece la funcionalidad común, y a continuación tres clases una para cada tipo de GUI comentada en requisito 1. Estas clases no están preparadas para el uso ya que no contienen componentes gráficos de edición por lo que no deberían ser 10
instanciables, clases abstractas, aunque la arquitectura del software de diseño de GUIs o del IDE podría no permitirlo. Aún más, dado el diseñador de GUIs debe ser el único que derive clases de esta jerarquía, los constructores deben ser métodos protegidos, requisito 7. La interfaz pública de la jerarquía debe contar con un método de inicialización de la GUI, la necesaria para la reusabilidad no de la que ya se ocupa la librería gráfica, un método para añadir una GUI-hija y otro para añadir listas de hijas para ser insertadas en páginas al mismo nivel la GUI-padre, esta es la interfaz pública de la implementación en C++. Estos métodos, dado que añadirían componentes gráficos reales, deben prestar atención a la preservación de las distribuciones (layouts) de los componentes, requisito 4. El resto de la interfaz es no público, requisito 7. Esto puede dar problemas de acceso entre clases derivadas, pensemos que los hijos de una determinada clase pueden ser de cualquier otra y será necesario acceder a sus métodos protegidos. El acceso de paquete proporciona la forma de solventar este problema, es similar a la declaración friend de C++. Recordemos que queremos proteger funcionamiento interno de la biblioteca del exterior, no de las clases que la componen que están estrechamente relacionadas. Para cumplir el requisito 1(a) aprovecharemos la estructura recursiva del patrón objeto compuesto. Cuando el usuario acepta la edición, ésta debe ser validada, si es necesario, y los campos de la clase editada actualizados. Los dos procedimientos 3, tienen una estructura similar. Ambos tiene una parte recursiva común a todas las clases de la jerarquía y una propia de cada GUI que el diseñador cree y que por lo tanto no puede estar implementada en la biblioteca, pero debemos forzar al diseñador a implementar. Para aceptar la validación de la edición se deben aceptar todas las validaciones de todas los GUis integrados y en ese caso se procede a la actualización de campos. Dado que la validación se puede ir realizando durante la edición, podemos liberar al diseñador de la obligación de implementar dicho procedimiento si así lo cree conveniente, la actualización de campos debe ser de forzosa implementación. En la implementación en C++ fue necesario crear un procedimiento de liberación de recursos, que es el último en ser llamado tanto si se acepta como si se rechaza la edición. En Java la liberación de recursos de memoria la realiza la máquina virtual, pero el procedimiento pudiera ser necesario para cerrar ficheros y otras acciones. El procedimiento de liberación de recursos sigue la misma estructura que los de validación y actualización. 2.3.2. El patrón observador (observer o listener) Un observador es un objeto que recibe notificaciones de cambio de estado de un objeto determinado y se las comunica a otros objetos, esto se realiza sin estar continuamente preguntando al objeto sobre su estado. Este patrón es de uso general en las librerías gráficas, Swing por ejemplo, para comunicar componentes gráficos entre sí, requisito 6. Dado que las componentes de las GUIs pueden ser cambiadas con cierta frecuencia, es especial en la fase de desarrollo de un programa, deseamos que el mecanismo de comunicación se realice sólo entre GUIs no entre componentes. Deben ser las propias GUIs los que encaminen las notificaciones de y hacia los componentes particulares, aquí se está empleando el patrón de indirección. El proceso de 3 Entendamos procedimiento como un método o conjunto de métodos. 11
comunicación debe ser establecido de forma automática desde dentro de la biblioteca. Será el diseñador de GUIs el encargado de decidir qué mensajes se notifican y cómo se procesan al recibirlos. El programador de aplicaciones debe permanecer ajeno a este proceso. 2.3.3. La factoría de GUIs reusables de estructura mínima Ya se comentó que una GUI reusable de estructura mínima es un GUI con botones, un componente gráfico que actúa como contenedor y quizás una vista de árbol para navegación. Estas GUIs se usan para envolver GUIs diseñadas sin botones. Dado que la creación de una GUI aunque sea de estructura mínima es compleja es conveniente delegar la creación en una clase que entienda de tales cuestiones, requisito 5, esto es una versión simple del patrón constructor (builder, no confundir con el método constructor de una clase). Esta clase debe poder acceder a las interioridades de los objetos que crea, como un mecánico a las piezas de un coche. 2.3.4. Reflexión El único escenario donde fue necesario usar la reflexión y no el polimorfismo en la implementación en C++, fue cuando las referencias (en C++ punteros) a los diálogos reutilizables eran devueltas por la librería gráfica como referencias a objetos de clases de la propia librería, por ejemplo como referencias a la clase base de los componentes gráficos. 3. Plan de trabajo 3.1. Desarrollo El alumno deberá desarrollar el proyecto siguiendo las fases habituales del ciclo de desarrollo de software. Deberá también aportar una arquitectura de la solución y un diseño técnico, donde se especifique la estructuración en módulos, la descripción de las interfaces, estructuras de datos fundamentales y los desarrollos algorítmicos no triviales. A continuación se implementará un prototipo de la solución aportada. Para la biblioteca se aconseja implementar primero el caso de los GUIs simples, de una sola página. A continuación se podría implementar el paso de mensajes entre GUIs. Seguir con las GUIs con pestañas y finalizar con las de vista de árbol, que son bastante más complejas. Todo proyecto software debe producir una documentación, habitualmente se considera: Requisitos del usuario y del sistema, manual del usuario, manual técnico, manual del instalador, etc. Una vez finalizado el trabajo, se aportará el resultado del mismo (implementación y documentación) para su incorporación en otros proyectos. El equipo docente ha elaborado un extenso material para la guía de los alumnos durante el desarrollo del proyecto. La pieza clave de este material la constituye una hoja de ruta que va marcando objetivos a conseguir hasta la finalización del proyecto. Este material se pondrá a 12
disposición de los alumnos tras la matrícula. El equipo docente realizará, si el alumno lo desea, un seguimiento del progreso en la consecución de los objetivos de la hoja de ruta. 3.2. Escritura de la memoria El alumno debe redactar la memoria del PFC para su presentación siguiendo las indicaciones y requisitos del Reglamento de PFC 4, de la ETSI Informática de la UNED. 3.3. Presentación y defensa pública Una vez concluidos los paso anteriores y revisado por el director, el alumno debe preparar la presentación y defensa pública del trabajo, apoyándose en los medios audiovisuales que crea necesarios, siguiendo las recomendaciones del director. 4. Material de consulta y herramientas 4.1. Java y Swing Si se sabe poco sobre Java se recomienda el libro gratuito on-line Introduction to Programming Using Java, que aunque está en inglés es de fácil compresión y trae un gran número de ejemplos resueltos, algunos hasta con applets para verlos funcionar. Trata desde cuestiones básicas hasta de nivel intermedio, tiene dos capítulos destinados a la programación de GUI. Con un contenido más extenso y tratado con más profundidad tenemos en libro gratuito online Thinking in Java, 3 a edición de Bruce Eckel, la cuarta edición está disponible en español (Piensa en Java, ed. Pearson) en los comercios. La documentación de Java original de Oracle, de imprescindible consulta, con gran número de tutoriales de todos los niveles. La documentación de la API es de navegación un poco oscura, ya que para consultar miembros de una clase puede ser necesario remontarnos en su jerarquía hasta encontrar una clase en la que se describan, recuérdese esta advertencia. La convención de nombres de Oracle, similar o otras. 4.2. Patrones de diseño Sobre patrones de diseño tenemos resumenes en patrones GoF y patrones Grasp. El libro libro gratuito on-line Thinking in Patterns de Bruce Eckel. El libro Patrones de Diseño de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, ed. Pearson. Obra capital sobre el tema, aunque no muy recomendable para principiantes. El libro UML y Patrones. Introducción al análisis y diseño orientado a objetos de Craig Larman, ed. Prentice Hall. Orientado a Java y muy práctico. 4 Este documento contiene enlaces a Internet, el seguimiento de enlaces debería estar habilitado en el visor pdf. 13
4.3. Herramientas para el programador Es necesario instalar el kit de desarrollo de Java de Oracle JDK 7 Update x. En realidad se puede emplear cualquier versión a partir de la 5, pero esta es la recomendada. Este kit se debe instalar antes que el IDE. Los entornos integrados de desarrollo (IDE) de código libre más utilizados para Java son NetBeans y Eclipse. Se usará NetBeans, versiones 7.x, que es de manejo más rápido y sencillo que Eclipse. Estos entornos de desarrollo contienen todas las herramientas necesarias para la programación y publicación de aplicaciones. 14