Propuesta de Oferta general para Proyecto Fin deCarrera (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 Melladojlaznarte@dia.uned.es.

Requisitos: Programación orientada a objetos en Java, programación de interfaces gráficas deusuario 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 au-tónomos en desarrollo en este departamento, está escrito en C++, usa la librería gráfica Qt-4 deNokia y su software de diseño de GUIs QtDesigner. Durante una fase del desarrollo se llegó ala conclusión de que era necesario diseñar una biblioteca que permitiera la reusabilidad de lasinterfaces gráficas (GUIs). Esta necesidad surgió en dos escenarios distintos, que pueden apa-recer mezclados. El primero era cómo crear una jerarquía de interfaces gráficas, generalmentediseñados con un diseñador gráfico, para editar una jerarquía de clases de manera que no seduplicara código ni componentes gráficos (widgets). El segundo cómo integrar interfaces gráfi-cas 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 componentesgráficos. Además el proceso debería ser transparente para usuarios y programadores, tanto losque diseñan las GUIs como los que las usan al programar aplicaciones. Precisaremos lo quese quiere decir con transparencia más adelante, ahora vamos a comentar un ejemplo de cadaescenario.

Para entender mejor los tamaños de las figuras diremos: que todas están escaladas, conel mismo factor de escala, con respecto a como se muestran en pantalla; a las GUIs cuandose 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. Hablaremosde la distribución de componentes más adelante.

Ejemplo 1: jerarquía de GUIs asociada a una jerarquía de clases. CyBeRSim dispone de uneditor 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 Qt-designer. Una determinada clase derivada sólo tiene un campo más a editar por lo que se diseñala GUI de la figura 2. El programador de aplicaciones con unas pocas líneas instancia la GUI de laclase base, la de la clase derivada y las ensambla en una GUI completa con botones1, ver figura3. Otra clase derivada tiene una gran cantidad de campos que editar, ver figura 4, de manera queal 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

1El hecho de que los diálogos con botones aparezcan traducidos al castellano al uso del sistema de internacio-nalización de Qt, no es parte de los requisitos de este proyecto, de hecho es el diseñador de GUIs el que debe lidiarcon la internacionalización.

2

Figura 3: GUI completa asociada a la clase derivada obtenida por integración en tiempo de eje-cució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 1y 4. a) Página correspondiente a la clase base, la GUI de la figura 1 se redimensiona adecuada-mente según tamaño del de la figura 4, que es la mayor de las dos. b) Página correspondiente ala clase derivada, ver figura 4.

4

Figura 6: GUI asociada a la clase base de la jerarquía de simulaciones, esta clase base no tieneasociados robots.

Ejemplo 2: integración de GUIs de objetos asociados Un objeto de la jerarquía de simula-ciones 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 deactividades, etc. Al editar los parámetros de la simulación y sus objetos asociados resulta máscómodo para el usuario tener todos las GUIs en una sólo y no tener que ir buscando por el sis-tema de menús dichas GUIs. De esta manera también se pueden editar conjuntamente camposde 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 objetode 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 convista de árbol. Esta GUI se podría haber diseñado sin botones y sería tarea del programador deaplicaciones envolverlo en una GUI con la vista de árbol y los botones, como en el ejemplo 1. Eneste caso la navegación por las distintas páginas de la GUI se realiza mediante una vista de árbolsituada en la región izquierda de la GUI, ver figura 8. Se decidió implementar la navegación deesta manera pues esta GUI contiene varios niveles de anidamiento, no se emplearon pestañaspues 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 laGUI 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 dichaGUI en la lista de la vista de árbol de la figura 8, este es un ejemplo de inserción de listas deGUIs relacionadas. El programador de aplicaciones ensambló la GUI de la figura 9 porque estaes 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 desdeel 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 derobots.

2.2. Requisitos

Para buscar una solución al problema expuesto en la sección 2.1 primero deberemos precisarlos 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 comomáximo dos GUIs2.

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 combinacionesno tengan mucho sentido. El nivel de anidamiento de GUIs, salvo para la simple, debe serteó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ómi-ca, por lo que lo editado en cada una de su páginas debe ser aceptado o rechazadocon una sola acción, una sola pulsación de botón del usuario al finalizar la edicióncompleta.

b) El diseñador de GUIs. Debe poder tratar estas GUIs como las normales de la libreríagráfica que se use, salvo, quizás, algunos pocos métodos añadidos para la reutiliza-ción y teniendo en cuenta que si existe un mecanismo previo de extensión de GUIs enla librería gráfica debería ser explícitamente anulado para que no entre en conflicto elmecanismo de reusabilidad aquí expuesto.

c) El programador de aplicaciones. Sólo debe tener acceso a la interfaz pública de lajerarquía de GUIs reusables, que, además de la propia de las GUIs normales de la

2Se 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íade simulaciones que sí tiene asociados robots. En la izquierda de las ventanas puede verse lavista de árbol usada para navegar por las GUIs, tiene tres niveles de anidación. En a) se muestrala GUI de la figura 6 y en b) la de la figura 7. Las GUIs de la figuras 6 y 7 se redimensionanadecuadamente 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 lajerarquía de robots, mostrando una de sus páginas, ver figura 7. Las dos páginas de esta GUItambié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 relacio-nadas y para la inicialización propia de los GUIs reusables, aparte de la que puedantener como GUIs normales. Además debe contar un procedimiento sencillo para elensamblado de basado en métodos polimórficos, de manera que cada clase a editarpueda ensamblar convenientemente su propio GUI reusable, ya sea por invocacióndel los mismos métodos en las clases de niveles más básicos de su jerarquía y/o porinvocació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 prin-cipalmente con el redimensionamiento de ventanas, ya sea por necesidades propias dela integración de GUIs y/o por acciones del usuario. Esta cuestión se resuelve mediantela distribución (layout) de los componentes gráficos que forman la GUI. Esta distribuciónno es una mera colocación sino también un procedimiento de recolocación y redimensio-namiento, bastante sofisticado, que poseen los componentes gráficos, especialmente losdiseñados para ser contenedores de componentes, en realidad una distribución es un ob-jeto asociado al componente. El requisito estético se concreta en que se debe diseñar elproceso de reutilización de manera que se preserven las distribuciones al integrar GUIspero sin que se acumulen los márgenes externos de las GUIs al anidar, ya que eso vareduciendo el espacio útil de la ventana.

5. Debe existir un mecanismo para crear GUIs de los tres tipos requeridos en el punto 1, conla estructura mínima: botones para aceptar la edición y rechazarla, contenedor apropiadocon distribución y vista de árbol para el último de los tipos requeridos. Estas GUIs las usa elprogramador de aplicaciones para envolver GUIs sin botones. Es preferible que se diseñenlas GUIs sin botones, salvo excepciones como la de la figura 6, para no tener el problemade qué hacer con ellos al integrar GUIs.

6. Comunicación entre GUIs integradas, hay que arbitrar un sistema de paso de mensajesentre 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 laimplementación de ciertos métodos, imprescindibles para el funcionamiento del proceso aimplementar, 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 seaposible. En la implementación en C++ se usó la introspección, cuando no se pudo hacerde 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 di-señan los GUIs usuales. Esto es una parte de la transparencia requerida para el diseñadorde GUIs, pero la separamos aparte por que añade complejidad extra al diseño del procesode reutilización. De hecho el patrón exacto que describiremos como solución del problemade la reusabilidad es posible que no pueda ser implementado para ciertos diseñadoresgráficos, o tenga una solución muy compleja, el problema proviene de la última parte delrequisito 4. En el caso de la implementación en C++ hubo suerte con el diseñador, perofue necesario conocer al detalle su funcionamiento para encontrar el modo de implementarel patrón de forma exacta. Si el alumno, investigando el funcionamiento del editor gráfi-co, llega a la conclusión de que no es posible la implementación exacta, debe ofrecer unrazonamiento 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, usandoel 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 yA2. 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. Di-señarlas sin botones, para que posteriormente sean envueltas en GUIs reusablescon estructura mínima, y darles una distribución adecuada. Usar cierta variedad decomponentes gráficos en las GUIs.

d) Crear tres clases B, C, D con al menos cinco campos cada una y de manera un objetode 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 debecontener vista de árbol y botones, los otros no, darles una distribución adecuada. Usarcierta variedad de componentes gráficos en las GUis. Mediante la comunicación deGUIs requerida en el punto 6, el cambio en un determinado componente gráfico dela GUI de D debe provocar un cambio en uno de B, p. ej. al deslizar un JSlider en laGUI 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 puedaneditar, 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 obje-tos agregados y los agregados a sus agregados. Las GUIs deben ser ensambladassiguiendo el procedimiento a desarrollar comentado en el requisito 3(c). La edicióndebe ser real, o sea, con actualización de campos en los objetos al aceptar la ediciónel usuario, previa validación de la coherencia de los datos.

g) Las GUIs ensamblados deben tener un buen comportamiento frente a redimensiona-mientos realizados por el usuario.

12. El proyecto debe estar debidamente documentado usando un sistema estándar de docu-mentació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 aobjetos

En esta sección se van a exponer o comentar patrones de diseño y otras técnicas de laprogramación orientada a objetos que proporcionan una solución al problema planteado quecumple los requisitos 1 a 8, salvo la parte final de 3(c). Para el requisito 9, al menos la soluciónde compromiso, se dispone de la tecnología JavaBeans. El requisito 10 está claro, en la sección4 se darán referencias a textos sobre Java, sobre patrones y herramientas de programación. Elrequisito 11 está claro, salvo en (f) relacionado con final de 3(c), para el que es necesario unnuevo 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 depatrones 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áficaque se use, así dispondremos de toda la funcionalidad de dicha clase y, además, el procesoirá cumpliendo los requisitos de transparencia pedidos. Derivarlos de clases más básicas de lajerarquí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): unajerarquía de clases en la que cada objeto tiene una lista de objetos hijos derivados de su mis-ma clase base que actúan polimórficamente. Esto permite construir, de forma recursiva, objetoscomplejos 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 tresclases una para cada tipo de GUI comentada en requisito 1. Estas clases no están preparadaspara 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 IDEpodría no permitirlo. Aún más, dado el diseñador de GUIs debe ser el único que derive clases deesta 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 paraañadir una GUI-hija y otro para añadir listas de hijas para ser insertadas en páginas al mismonivel 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 delas distribuciones (layouts) de los componentes, requisito 4.

El resto de la interfaz es no público, requisito 7. Esto puede dar problemas de acceso entreclases derivadas, pensemos que los hijos de una determinada clase pueden ser de cualquierotra y será necesario acceder a sus métodos protegidos. El acceso de paquete proporciona laforma de solventar este problema, es similar a la declaración friend de C++. Recordemos quequeremos proteger funcionamiento interno de la biblioteca del exterior, no de las clases que lacomponen que están estrechamente relacionadas.

Para cumplir el requisito 1(a) aprovecharemos la estructura recursiva del patrón objeto com-puesto. Cuando el usuario acepta la edición, ésta debe ser validada, si es necesario, y los camposde la clase editada actualizados. Los dos procedimientos3, tienen una estructura similar. Ambostiene una parte recursiva común a todas las clases de la jerarquía y una propia de cada GUI queel diseñador cree y que por lo tanto no puede estar implementada en la biblioteca, pero debe-mos forzar al diseñador a implementar. Para aceptar la validación de la edición se deben aceptartodas las validaciones de todas los GUis integrados y en ese caso se procede a la actualizaciónde campos. Dado que la validación se puede ir realizando durante la edición, podemos liberaral diseñador de la obligación de implementar dicho procedimiento si así lo cree conveniente, laactualización de campos debe ser de forzosa implementación. En la implementación en C++ fuenecesario crear un procedimiento de liberación de recursos, que es el último en ser llamado tan-to si se acepta como si se rechaza la edición. En Java la liberación de recursos de memoriala realiza la máquina virtual, pero el procedimiento pudiera ser necesario para cerrar ficheros yotras acciones. El procedimiento de liberación de recursos sigue la misma estructura que los devalidació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 deter-minado y se las comunica a otros objetos, esto se realiza sin estar continuamente preguntandoal objeto sobre su estado. Este patrón es de uso general en las librerías gráficas, Swing porejemplo, para comunicar componentes gráficos entre sí, requisito 6. Dado que las componentesde las GUIs pueden ser cambiadas con cierta frecuencia, es especial en la fase de desarrollode un programa, deseamos que el mecanismo de comunicación se realice sólo entre GUIs noentre componentes. Deben ser las propias GUIs los que encaminen las notificaciones de y hacialos componentes particulares, aquí se está empleando el patrón de indirección. El proceso de

3Entendamos 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á eldiseñador de GUIs el encargado de decidir qué mensajes se notifican y cómo se procesan alrecibirlos. 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 com-ponente gráfico que actúa como contenedor y quizás una vista de árbol para navegación. EstasGUIs se usan para envolver GUIs diseñadas sin botones. Dado que la creación de una GUI aun-que sea de estructura mínima es compleja es conveniente delegar la creación en una clase queentienda de tales cuestiones, requisito 5, esto es una versión simple del patrón constructor (buil-der, no confundir con el método constructor de una clase). Esta clase debe poder acceder a lasinterioridades 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 imple-mentación en C++, fue cuando las referencias (en C++ punteros) a los diálogos reutilizables erandevueltas por la librería gráfica como referencias a objetos de clases de la propia librería, porejemplo 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 desarrollode software. Deberá también aportar una arquitectura de la solución y un diseño técnico, dondese especifique la estructuración en módulos, la descripción de las interfaces, estructuras de datosfundamentales y los desarrollos algorítmicos no triviales.

A continuación se implementará un prototipo de la solución aportada. Para la biblioteca seaconseja implementar primero el caso de los GUIs simples, de una sola página. A continuaciónse podría implementar el paso de mensajes entre GUIs. Seguir con las GUIs con pestañas yfinalizar con las de vista de árbol, que son bastante más complejas.

Todo proyecto software debe producir una documentación, habitualmente se considera: Re-quisitos 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 documen-tación) para su incorporación en otros proyectos.

El equipo docente ha elaborado un extenso material para la guía de los alumnos duranteel desarrollo del proyecto. La pieza clave de este material la constituye una hoja de ruta queva 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 indicacionesy requisitos del Reglamento de PFC4, 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 prepararla presentación y defensa pública del trabajo, apoyándose en los medios audiovisuales que creanecesarios, 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 Program-ming Using Java, que aunque está en inglés es de fácil compresión y trae un gran número deejemplos 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 on-line Thinking in Java, 3a 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úmerode 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íahasta 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.

4Este 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 sepuede emplear cualquier versión a partir de la 5, pero esta es la recomendada. Este kit se debeinstalar antes que el IDE.

Los entornos integrados de desarrollo (IDE) de código libre más utilizados para Java sonNetBeans y Eclipse. Se usará NetBeans, versiones 7.x, que es de manejo más rápido y sencilloque Eclipse. Estos entornos de desarrollo contienen todas las herramientas necesarias para laprogramación y publicación de aplicaciones.

14