AIDA - software para procesamiento de imágenes digitales

Texto completo

(1)AIDA – Software para Procesamiento de Imágenes Digitales. Proyecto Dirigido Elaborado Por Georgean Britton Dirigido por Marcela Hernández. Universidad de los Andes Bogotá Julio de 2004.

(2) INDICE. 1.. Introducción ............................................................................................................... 3 1.1. Objetivo General ................................................................................................ 3 1.2. Antecedentes ...................................................................................................... 3 1.3. Justificación ....................................................................................................... 3 1.4. Objetivos específicos .......................................................................................... 4 1.5. Ambiente de implementación y restricciones ...................................................... 4 2. Marco Teórico............................................................................................................ 5 2.1. Visualization ToolKit - VTK .............................................................................. 5 2.1.1. VTK y Java................................................................................................. 6 2.1.2. Evitando el SandBox................................................................................... 6 2.2. Mapas Conceptuales ........................................................................................... 8 2.3. Teoría de Grafos................................................................................................. 8 3. AIDA ......................................................................................................................... 9 3.1. Análisis .............................................................................................................. 9 3.1.1. Manejo del grafo......................................................................................... 9 3.1.2. Procesamiento de imágenes......................................................................... 9 3.1.3. Ayuda en Línea y Mapa Conceptual.......................................................... 11 3.2. Diseño .............................................................................................................. 11 3.2.1. VGJ .......................................................................................................... 11 3.2.2. AIDA........................................................................................................ 15 3.3. Implementación ................................................................................................ 21 4. Resultados................................................................................................................ 22 4.1. Defectos detectados .......................................................................................... 23 4.2. Trabajo futuro................................................................................................... 23 5. Conclusiones ............................................................................................................ 24 6. Bibliografía .............................................................................................................. 25.

(3) 1. Introducción 1.1.. Objetivo General. Desarrollar un software de procesamiento y análisis de imágenes digitales como herramienta de apoyo a la educación.. 1.2.. Antecedentes. Actualmente, los talleres prácticos del curso de Procesamiento y Análisis de Imágenes Digitales del Departamento de Sistemas y Computación, se apoyan en la herramienta WinImag. WinImag es una software de procesamiento de imágenes digitales, desarrollado usando la librería libIDO [1]. El software utilizado actualmente satisface las necesidades de apoyo al aprendizaje salvo en las siguientes características: - Idioma: la versión del software está en francés, característica que añade complejidad a su manejo. - Ayuda no integrada: el manual de la aplicación es un documento de hipertexto, que no se accede desde la aplicación. - Código no disponible para futuras modificaciones. - No es accesible desde Internet. - El usuario no puede salvar un trabajo intermedio. - Una vez aplicadas de manera consecutiva, una serie de operaciones sobre una imagen, no es posible recuperarla. El resultado final es visualizado por el usuario, pero no es posible conocer las operaciones que se aplicaron, ni los resultados intermedios.. 1.3.. Justificación. Desde el punto de vista pedagógico, los Materiales Educativos Computarizados (MECs) tratan, ante todo, de complementar lo que con otros medios y materiales de EnseñanzaAprendizaje (E-A) no es posible o es difícil de lograr [2]. En el caso de la enseñanza de algoritmos de procesamiento de imágenes, el objetivo de la aplicación es permitir al estudiante poner a prueba sus conocimientos a través de escenarios qué pasa si. El objetivo de este proyecto es por consiguiente producir un software de procesamiento de imágenes digitales, para ser usado por los estudiantes de la universidad, que ofrezca mejoras en las características antes descritas. El software debería permitir al usuario interactuar cómodamente con la ayuda, ver el efecto intermedio de los algoritmos aplicados, guardar su trabajo en cualquier momento y abrir la posibilidad de extender la funcionalidad con desarrollos futuros, por ejemplo, aprovechando la integración entre Java e Internet..

(4) 1.4. -. -. -. Objetivos específicos. Desarrollar el software con las mismas funciones que tiene WinImag actualmente, cambiando la interfaz para introducir el concepto de tubería de procesamiento, descrito más adelante. Documentar la arquitectura y el código fuente de la aplicación, para que ésta pueda ser modificada en el futuro. Aplicar una metodología en el proceso de desarrollo que garantice la calidad del producto. Introducir un manual de ayuda en línea fácil de acceder y que utilice la representación con Mapas Conceptuales [3] recomendada por el grupo de Informática Educativa. Desarrollar el software de tal forma que pueda ser accedido por Internet utilizando un navegador. Permitir al usuario grabar su trabajo en cualquier momento para continuar más adelante. Permitir al usuario ver el efecto intermedio de los algoritmos que se aplican a una imagen, facilitando la experimentación de los conceptos teóricos. Utilizar idioma inglés en la interfaz.. 1.5.. Ambiente de implementación y restricciones. La aplicación fue desarrollada en lenguaje Java, utilizando la herramienta JBuilder X de Borland. Para las funciones gráficas se utilizó la librería VTK. El software fue desarrollado para que funcione sobre plataforma Windows XP Professional con Internet Explorer 5 o superior. Aunque no se ejecutaron pruebas formales en otros sistemas operativos, una característica de Java es que las aplicaciones desarrolladas se pueden ejecutar en cualquier sistema..

(5) 2. Marco Teórico 2.1.. Visualization ToolKit - VTK. VTK es una herramienta destinada a la visualización de objetos gráficos 3D, así como al procesamiento y visualización de imágenes digitales utilizada ampliamente en el ámbito de la programación de aplicaciones de visualización. VTK es una librería de clases en C++ y una serie de capas de interfaz que incluye Tlc/Tk, Java y Python [4]. Para el desarrollo de AIDA se utilizó VTK porque ofrece muchos de los algoritmos que se utilizan en el curso de procesamiento de imágenes y además se integra con Java, lo que constituye uno de los prerrequisitos del proyecto. VTK usa un modelo de visualización basado en el paradigma flujo-datos (data-flow). En este paradigma los módulos se conectan entre sí formando una red. Los módulos realizan operaciones algorítmicas sobre los datos mientras éstos fluyen a través de la red. La ejecución de la red de visualización es controlada en respuesta a demanda de datos (por demanda) o en respuesta a entradas del usuario (por eventos). El atractivo de este modelo es que es flexible y puede ser adaptado rápidamente a diferentes tipos de datos o a nuevos algoritmos [17]. En VTK el modelo de visualización consta de dos tipos básicos de objetos: objetos de datos y objetos de procesos (Fig. 1). Objetos de procesos son los módulos, o porciones algorítmicas de la red de visualización. Los objetos de datos representan y habilitan las operaciones en los datos que fluyen a través de la red.. Figura 1. Modelo de visualización. Los objetos de proceso A, B y C reciben o producen uno o más objetos de datos. Los objetos A, B y C son fuente, filtro y mapeador respectivamente.. Los objetos de proceso se pueden clasificar en tres tipos: fuentes, filtros y mapeadores (mappers) (Fig. 2). Los objetos fuente inician la red y generan uno o más salidas. Los filtros requieren una o más entradas y producen una o más salidas. La red es terminada por los mapeadores, que requieren una o más entradas..

(6) F u e n te. F iltro. M apeador. Figura 2. Tipos de objeto de procesos. Objetos fuente no reciben entradas y producen una o más salidas. Objetos filtro reciben una o más entradas y producen una o más salidas. Objetos mapeadores reciben una o más entradas y producen ninguna salida.. El desarrollo de la Tubería de Procesamiento de AIDA está inspirado en el modelo de visualización de VTK. Como se verá más adelante, existe una correspondencia entre la red de visualización y la Tubería de Procesamiento; y entre los objetos filtro de AIDA y VTK.. 2.1.1. VTK y Java Aunque no hay una versión 100% Java de VTK, existen unos wrappers que permiten hacer llamados desde Java. Los wrappers son al final un conjunto de DLLs (Dinamic Link Libraries[5]) y archivos JAR que hacen la interfaz entre llamados en Java y las librerías de VTK. La consecuencia de esta relación es que AIDA debe cargar en memoria principal una serie de DLLs. Esta es una función potencialmente peligrosa y por eso ha sido restringida para ser usada desde Applets. El peligro radica en que un usuario puede ir a una página, descargar un Applet y éste último ejecutar aplicaciones que se encuentran en la máquina del usuario, por ejemplo un virus puesto previamente por un atacante sin que el usuario lo notara. El virus o programa maligno se ejecutaría con los privilegios del usuario causando muchísimo daño. Para evitar que los Applets pudieran causar daño, SUN introdujo en la arquitectura de Java el concepto de SandBox.. 2.1.2. Evitando el SandBox El concepto de Sandbox, originalmente incluido en la versión 1.0 del JDK, establecía que las aplicaciones locales tenían acceso a todos los recursos locales, mientras que las aplicaciones remotas, como los Applets, solo tenían acceso a los recursos disponibles en el SandBox (Fig. 3)..

(7) Figura 3. Modelo de seguridad de Java 1.0. Código remoto con acceso limitado a recursos del SandBox. Tomado de: http://java.sun.com/j2se/1.3/docs/guide/security/spec/security-spec.doc1.html. Actualmente el concepto ha evolucionado y establece que cualquier código, local o remoto, se ejecuta en el contexto de una política de seguridad que define el acceso a los recursos sensibles que tendrá la aplicación (Fig. 4).. Figura 4. Modelo de seguridad de Java 2.0. Políticas de seguridad definen acceso a recursos. Tomado de: http://java.sun.com/j2se/1.3/docs/guide/security/spec/security-spec.doc1.html. Dicho lo anterior, AIDA tenía una dificultad al ser una Applet porque debía evitar las restricciones que implica el SandBox, la forma que se escogió para lograrlo fue firmar digitalmente el código del Applet de tal forma que la Java Virtual Machine “confiara” en él. El proceso para lograrlo es el siguiente [6]: -. Compilar el applet Crear un archivo JAR Generar las llaves de seguridad [7] Firmar el archivo JAR Exportar un Certificado Público [8] Importar el Certificado como un Certificado Confiable.

(8) -. Crear el archivo de políticas Ejecutar el applet. 2.2.. Mapas Conceptuales. Son herramientas para organizar y representar conocimiento. Incluyen conceptos, usualmente encerrados en círculos o cajas, y relaciones entre los conceptos o proposiciones, indicadas mediante líneas que conectan los conceptos. Las palabras en la línea especifican la relación que hay entre los conceptos [9]. Los mapas conceptuales se representan jerárquicamente, con los conceptos más generales en la parte superior del mapa y los más específicos hacia abajo. Otra característica importante es la utilización de enlaces-cruzados, que representan relaciones entre conceptos en diferentes dominios del mapa conceptual. Los enlaces-cruzados son útiles para ver como se relacionan dominios de conocimiento diferentes. En el desarrollo de AIDA se relacionó un mapa conceptual con el dominio de conocimiento enseñado a los alumnos en la universidad. Para esto se utilizaron las CMAP Tools, que se obtienen gratuitamente en http://cmap.ihmc.us/download/.. 2.3.. Teoría de Grafos. Internamente, AIDA utiliza grafos dirigidos sin ciclos para representar la información. A continuación se presentan algunas definiciones importantes de teoría de grafos. Grafo: Informalmente, un grafo es un conjunto de elementos conectados por arcos. Cada elemento se llama vértice o nodo. Formalmente, un grafo es un conjunto de vértices y una relación binaria entre vértices, la adyacencia [10]. Grafo Dirigido: Un grafo dirigido es aquel en el que cada arco se puede seguir de un nodo a otro. Grafo Sin Ciclos: Un grafo sin ciclos es aquel en el que no existe ninguna ruta que conecte a un nodo con él mismo. Ruta: Una ruta es un conjunto de arcos de un grafo donde cada vértice tiene un arco que lo conecta con el siguiente. La red de visualización de VTK y la Tubería de Procesamiento de AIDA son grafos. En el caso de AIDA se trata de un grafo dirigido sin ciclos. Los nodos representan objetos de procesos y los arcos indican la dirección de los datos. Buena parte del desarrollo en AIDA tiene que ver con administrar la estructura de datos que representa el grafo y hacer fluir a través de éste los datos que se van transformando en cada nodo del grafo..

(9) 3. AIDA 3.1.. Análisis. AIDA es una aplicación educativa de procesamiento de imágenes digitales. Utiliza un pipeline (tubería) a través del cuál las imágenes van transformándose, permitiendo al usuario ver el efecto de los algoritmos sin perder la imagen original. El pipeline diferencia a AIDA de otras aplicaciones del área porque habilita la posibilidad de experimentar el efecto aditivo de los algoritmos sobre las imágenes, a medida que éstas van avanzando el flujo definido por el usuario. También le permite al usuario aplicar fácilmente el mismo pipeline a una imagen diferente, guardar el pipeline o cargar uno guardado previamente. La funcionalidad de AIDA se puede dividir en dos partes, manejo del grafo y procesamiento de imágenes.. 3.1.1. Manejo del grafo AIDA debe mantener la representación interna del grafo como estructura de datos y permitir la modificación de esa estructura a través de la interfaz gráfica de usuario (GUI). Ejemplos de las posibles interacciones son: crear nodos, crear arcos, eliminar nodos, eliminar arcos, cambiar la posición de los nodos, cambiar el tamaño de los nodos, seleccionar uno o más nodos y arcos. Durante el análisis se detectó la complejidad que implicaba el manejo del grafo y se decidió buscar una aplicación hecha en Java que ofreciera la funcionalidad y construir sobre ésta. En Internet se encuentran muchas aplicaciones del estilo que se necesitaba. Algunas manejaban solamente la estructura de datos, otros también incluían la manipulación gráfica. Se escogió la aplicación Visualizing Graphs with Java (VGJ), porque ofrece las dos funcionalidades requeridas, está escrita en Java y su arquitectura es comprensible, fácil de modificar. VGJ, Visualizing Graphs with Java, es un proyecto del departamento de Ingeniería de Software y Ciencias de la Computación de la Universidad de Auburn. VGJ ofrece una herramienta para dibujar y desplegar grafos. Los grafos pueden ser introducidos a través de texto usando GML, o a través del editor de grafos incluido. Después el usuario puede seleccionar un algoritmo para organizar la disposición del grafo en la pantalla [11]. El desarrollo de VGJ se detuvo en 1998, algunos grupos han seguido desarrollando sobre el código original pues VGJ puede ser distribuido bajo los términos de la licencia GNU General Public License, Versión 2 [12].. 3.1.2. Procesamiento de imágenes Para AIDA se seleccionó VTK como herramienta de procesamiento de imágenes pero se decidió mantener la interacción con las librerías en el mínimo posible para que en el futuro.

(10) fuera fácil añadir otras librerías. Esto considerando que ninguna librería ofrece el 100% de la funcionalidad requerida. El impacto de esta decisión estriba en que la actualización de la tubería de procesamiento debía ser codificada en AIDA, no utilizando la funcionalidad que al respecto ofrece VTK. 3.1.2.1. Tubería de Procesamiento La tubería de procesamiento (TP) es la combinación de la representación del grafo con la lógica de actualización cuando se presentan cambios. Para entender la TP, es importante conocer las funciones de los arcos y nodos que se definieron en AIDA.. 3.1.2.1.1.. Función de los arcos. La función de los arcos es indicar la dirección y el contenido de los datos en la tubería. Los arcos no efectúan cambios en los datos. Reciben las salidas generadas por un nodo y las mueven hacia el nodo de destino al que están conectados. Los arcos solo pueden conectarse a nodos que producen salidas.. 3.1.2.1.2.. Función de los nodos. Los nodos son de diferentes tipos según la funcionalidad que ofrecen en la TP. - Fuentes: Crean información o la leen información de un archivo y la introducen a la TP. - Filtros: reciben datos, los transforman aplicando un algoritmo y unos parámetros de entrada, y producen una salida de vuelta a la TP. - Escritores: reciben datos de la TP y la escriben al disco. No producen salidas de vuelta a la TP (Fig. 5). - Visualizadores: son filtros que reciben entradas pero no las modifican.. Figura 5. Tipos de nodo en AIDA. Observar correspondencia con objetos de proceso en vtk.. 3.1.2.1.3.. Manejo de cambios. En la Tubería de Procesamiento los datos siempre deben estar actualizados. Cada vez que se presenta un cambio, la información se actualiza en cascada. El modelo que se utiliza en AIDA establece que el nodo que recibe un cambio inicia la actualización avisándole a los nodos siguientes que deben actualizarse (Fig. 6)..

(11) Figura 6. Actualización en cascada de la Tubería de Procesamiento.. Aunque VTK internamente administra la actualización y validez de los datos en la tubería, en AIDA se implementó la funcionalidad para minimizar la dependencia de VTK y abrir la posibilidad de utilizar otras librerías en el futuro.. 3.1.3. Ayuda en Línea y Mapa Conceptual AIDA ofrece a los estudiantes un enlace fácil y rápido con el manual de uso de la aplicación, en formato de hipertexto. También ofrece la posibilidad de explorar el mapa conceptual del curso, en el que se da contexto a los algoritmos ofrecidos por AIDA. Es recomendable integrar el manual de uso de la aplicación con el mapa conceptual para que el usuario pueda saber la teoría detrás de los algoritmos que ofrece la aplicación. Otro desarrollo interesante sería permitir a los usuarios trabajar los talleres del curso desde la aplicación. Por ejemplo, un estudiante podría conectarse desde AIDA a la página del curso, bajar un taller, realizarlo y guardarlo nuevamente en la página del curso. Esto abriría opciones de colaboración interesantes, como saber si un mismo problema se puede resolver usando diferentes combinaciones de algoritmos.. 3.2.. Diseño. A continuación se presentará un contraste entre la estructura de clases de VGJ y AIDA, resaltando los cambios fundamentales. Para facilitar el análisis se han omitido del diagrama de clases herencias y clases irrelevantes en la comparación con AIDA.. 3.2.1. VGJ Se observa que VGJ fue diseñado para administrar un grafo en el que todos los nodos pertenecen a la misma clase y almacenan el mismo tipo de datos. Por eso existe una única ventana para modificar los nodos y otra para modificar los arcos, NodePropertiesDialog y EdgePropertiesDialog respectivamente. Esos dos diálogos son instanciados por la clase GraphCanvas cuando el usuario hace doble clic sobre un nodo o arco. La siguiente figura es un diagrama de clases simplificado de VGJ (Fig. 7).

(12) Figura 7. Diagrama de clases de VGJ..

(13) Las clases más importantes en VGJ son: Graph -nodeList -edges +insertEdge() +deleteEdge() +insertNode() +deleteNode() +firstNode() +getNodeFromIndex(). Node -width -height -x -y -image +getPosition() +setPosition() +getSize() +setSize() +setImage() +draw(). NodeList -nodes -numNodes +addNode() +removeNode() +firstNode() +nextNode(). NodePropertiesDialog -node -data +setNode() +handleEvent(). Descripción Administra la representación del grafo. Atributos Lista de nodos y arcos. Funciones Buscar, insertar, eliminar y modificar nodos, y arcos.. Descripción Representa un nodo del grafo. Administra sus propias variables de posición y tamaño. Almacena datos. Se dibuja a sí mismo en la pantalla. Atributos Posición y tamaño. Funciones Modificar posición y tamaño. Actualizar datos. Dibujar el nodo en la pantalla. Descripción Administra la lista de nodos del grafo. VGJ representa el grafo como una lista de nodos más un conjunto de parejas de nodos que son los arcos. Atributos Lista de nodos. Número de nodos actualmente en la lista. Funciones Insertar y remover nodos, recorrer la lista de nodos.. Descripción Ventana de diálogo que permite modificar características del nodo, como los datos o el texto que lo identifica. Atributos Nodo que está modificando. Datos del nodo. Funciones Cambiar el nodo que es está modificando..

(14) Edge -head -tail +getHead() +getTail() +draw(). EdgePropertiesDialog -edge -graph +setEdge() +handleEvent(). VGJ::VGJ +action(). Descripción Representa un arco del grafo. Se dibuja a sí mismo en la pantalla. Atributos Origen y destino del arco. Funciones Obtener el nodo origen y el nodo destino. Dibujar el arco en la pantalla.. Descripción Ventana de diálogo que permite modificar características del arco. Atributos Arco que está modificando. Referencia al grafo completo. Funciones Cambiar el arco que se está modificando. Descripción Applet sencillo que contiene un único botón. Al presionar el botón se abre la ventana de la aplicación. Atributos Funciones Crear la ventana de aplicación y la muestra.. GUI::GraphWindow -graph -graphCanvas -menu -controls +action() +keyDown() +selectNode(). GUI::GraphCanvas -selectedNode -mouseMode -nodePropDialog -edgePropDialog -selectedEdge +keyDown() +mouseDown() +deleteSelected() +drawObjects(). Descripción Ventana principal de la aplicación. Contiene los controles principales de la aplicación y la barra de menú. Atributos El grafo, el graphCanvas que es la ventana donde efectivamente se pinta y manipula el grafo. Menú y controles. Funciones Administrar eventos de teclado y mouse. Descripción Representa el lugar donde se dibuja el grafo y donde se administran todos los eventos de entrada del usuario sobre el grafo, como mover un nodo, seleccionarlo o cambiar el tamaño. Atributos Tiene atributos para administrar las interacciones del usuario con el grafo, como los nodos que están seleccionados o la acción actual del usuario sobre la aplicación, por ejemplo, si está insertando o eliminando un nodo. Guarda una referencia al grafo para modificarlo según sea necesario..

(15) Funciones Administrar eventos de teclado y mouse. Actualiza la representación visual del grafo cuando ocurren cambios. Como se verá más adelante, las diferencias más importantes entre AIDA y VGJ radican en que AIDA define diferentes tipos de nodos y por consiguiente, diferentes ventanas de actualización. Adicionalmente, cada tipo de nodo debe dibujarse en la pantalla en forma diferente.. 3.2.2. AIDA En AIDA se introduce una arquitectura que permite utilizar diferentes tipos de nodos: lectores, escritores, visualizadores y filtros. Los lectores equivalen a fuente, no reciben entradas y producen datos de salida. Puntualmente permiten leer archivos en formato .JPG y .BMP. Los escritores equivalen a objetos mapeadores, reciben la información de la tubería y la escriben al disco en formato .JPG. Los filtros son objetos que aplican un algoritmo sobre los datos que reciben y entregan un resultado de vuelta a la tubería. Los visualizadores se usan para mostrar los datos en la pantalla, en la implementación se manejan como filtros que devuelven los datos que reciben sin hacerles modificación alguna. Para lograrlo se definieron dos interfaces, ISource y IFilter como se describe a continuación. 3.2.2.1. ISource Representa nodos fuente de datos en la tubería de procesamiento, no ofrece manejo de datos de entrada. ISource introduce las funciones update, setLastUpdated y getLastUpdated, que serán utilizadas en la lógica de la Tubería de Procesamiento para mantener los datos actualizados todo el tiempo. Todos los objetos que producen datos deben implementar esta interfaz: lectores y filtros (Fig. XX). «interface» graph::ISource +getNumberOfOutputs() : int +getOutputs() : HashTable +update() : void +setLastUpdated(in time : double) : void +getLastUpdated() : double. Figura 8. Interfaz ISource. Encargada de abstraer la funcionalidad de nodos que producen salidas.. 3.2.2.2. IFilter Representa los nodos que reciben uno o más datos y los procesan, produciendo cero o más salidas. Introduce funcionalidad para manejar entradas: saber cuántas entradas tiene el filtro y darles el valor deseado. Todos los filtros deben implementar la funcionalidad descrita en IFilter (Fig. 9)..

(16) «interface» graph::IFilter +getNumberOfInputs() : int +getAvailableInputs() : HashTable +getInputs() : Vector +setNthInput(). Figura 9. Interfaz ISource. Encargada de abstraer la funcionalidad de nodos que aceptan entradas de información.. En el siguiente diagrama (Fig. 10) se muestran las herencias relacionadas con IFilter y ISource. Por una parte se ve que la clase Reader implementa la funcionalidad de ISource, como debe ser, puesto que un lector obtiene sus datos de un archivo en el disco y no de un nodo anterior en la tubería. Por otra parte, la interfaz IFilter extiende la funcionalidad de ISource, creando una definición de clase que recibe y produce datos. Finalmente, la implementación de IFilter se hace en la clase Filter, de la cuál heredarán todos los filtros que se implementen en AIDA. 3.2.2.3. Integración con VGJ Con la introducción de las interfaces descritas, se crea la arquitectura necesaria para implementar la lógica de procesamiento de imágenes que utiliza la tubería. Se tiene fuentes de datos, filtros y escritores. También se tienen funciones de actualización para habilitar el flujo de cambios a través de los nodos afectados. Sin embargo, la estructura debe integrarse con VGJ para no perder el manejo de nodos, tanto gráficos como en el modelo de datos, que era la intención inicial. « in te r fa c e » IS o u r c e + g e tN u m b e r O fO u tp u ts ( ) : in t + g e tO u tp u ts ( ) : H a s h T a b le + u p d a te ( ) : v o id + s e tL a s tU p d a te d (in tim e : d o u b le ) : v o id + g e tL a s tU p d a te d () : d o u b le. R ead er -file N a m e : S tr in g + g e tF ile N a m e ( ) : S tr in g + s e tF ile N a m e ( in file N a m e : S tr in g ) : v o id + g e tO u tp u t( ) : v tk Im a g e D a ta. « in te r fa c e » IF ilt e r + g e tN u m b e r O fIn p u ts () : in t + g e tA v a ila b le In p u ts ( ) : H a s h T a b le + g e tIn p u ts ( ) : V e c to r + s e tN th In p u t( ). F ilt e r + u p d a te ( ) : v o id. Figura 10. Herencias de ISource e IFilter.. Para poder utilizar la funcionalidad original de VGJ es necesario hacer lo siguiente: - Heredar de la clase Node. - Heredar de Filter. - Modificar el manejo de los NodePropertiesDialog..

(17) 3.2.2.3.1.. Heredar de Node. En el siguiente diagrama (Fig. 11) se muestra la forma en que Filter hereda de Node. Node +clearChild(in child : int) : void +getChildren() : Set +draw() : void +setChild(in child : int) : void +setImageSource(in image_source : String) : void +setPosition() : void +getOutput() : vtkImageData +showPropertiesDialog() : void. «interface» ISource +getNumberOfOutputs() : int +getOutputs() : HashTable +update() : void +setLastUpdated(in time : double) : void +getLastUpdated() : double. «interface» IFilter +getNumberOfInputs() : int +getAvailableInputs() : HashTable +getInputs() : Vector +setNthInput(). Filter +update() : void. Figura 11. Filter hereda de Node.. De esta forma todos los filtros en AIDA son nodos en VGJ y queda intacta la funcionalidad de manejo de grafos que se tenía.. 3.2.2.3.2.. Heredar de Filter. Es necesario implementar las clases correspondientes a cada uno de los filtros, heredando de Filter. Se debe aclarar que Filter es realmente una clase abstracta, es decir, no implementa todos lo métodos especificados en las interfaces. Las herencias de Filter se muestran a continuación (Fig. 12)..

(18) Filter +update() : void. Convolve. Threshold. Variance3D. -filtroVTK : vtkImageConvolve. -filtroVTK : vtkImageThresholding. -filtroVTK : vtkImageVariance3D. Diffusion. Sobel. Median. -filtroVTK : vtkImageAnisotropicDiffusion2D. -filtroVTK : vtkImageSobel2D. -filtroVTK : vtkImageMedian3D. Viewer. Writer -vtkWriter : vtkJPEGWriter -fileName : String. Figura 12. Todos los filtros heredan de Filter.. Se destaca en los filtros la utilización de clases específicas de VTK: vtkImageConvolve, vtkImageThresholding, vtkImageSobel, etc. Esas clases de VTK son las que ejecutan el algoritmo sobre los datos de entrada y generan las salidas de cada filtro. La clase Writer es un caso especial de Filter porque su número de salidas es igual a cero.. 3.2.2.3.3.. Heredar de NodePropertiesDialog. En VGJ solo existe una clase para manejar las propiedades de los nodos, en AIDA se necesita una ventana para cada tipo de nodo. Por otro lado, en VGJ la ventana de propiedades es instanciada por la clase GraphCanvas, esa forma de hacerlo no es apropiada porque implica que GraphCanvas conozca el tipo de cada nodo y el tipo de cada ventana de propiedades. Lo deseable es que para GraphCanvas y para Graph los nodos sean solo de tipo Node, y que la funcionalidad de AIDA maneje el resto del problema. La solución implementada es que cada nodo sea dueño de su propia ventana de propiedades y que ofrezca una función showPropDialog() para mostrarlo. De esta forma se minimizan los cambios en GraphCanvas, que ahora debe llamar la función showPropDialog() sin importar el tipo de nodo. Notar en la siguiente gráfica la función showPropDialog() de Node y la función show() de NodePropertiesDialog() (Fig. 13)..

(19) Node. NodePropertiesDialog. +clearChild(in child : int) : void +getChildren() : Set +draw() : void +setChild(in child : int) : void +setImageSource(in image_source : String) : void +setPosition() : void +getOutput() : vtkImageData +showPropertiesDialog() : void. +setNode(in node_in : Node) : void +action() : boolean +handleEvent(in event : Event) : boolean -setValues_() : boolean +show() : void +hide() : void. Figura 13. Nodos son dueños de su ventana de propiedades.. En la siguiente gráfica (Fig. 14) se muestran las herencias de NodePropertiesDialog. NodePropertiesDialog -currentData_ : String -node_ : Node +setNode(in node_in : Node) : void +action() : boolean +handleEvent(in event : Event) : boolean -setValues_() : boolean +show() : void +hide() : void. DiffusionPropDialog. ReaderPropDialog. SobelPropDialog. ThresholdPropDialog. Variance3DPropDialog. MedianPropDialog. ConvolvePropDialog. WriterPropDialog. Figura 14. Las ventanas de propiedades heredan de NodePropertiesDialog.. En la siguiente gráfica (Fig. 15) se presenta el diagrama de clases implementado en AIDA..

(20) XMLBridge. GraphWindow2 1. -Contiene. «instance». HelpViewer 1. -Es contenido por. VGJ GraphCanvas -Dibuja Set -Es dibujado por NodeList. HashTable Contiene. Graph. Es contenido por 1. -Administra. *. -Es Administrado por. EdgePropertiesDialog. Node. Edge. NodePropertiesDialog. ConvolvePropDialog ReaderPropDialog. «interface» ISource. MedianPropDialog. SobelPropDialog. Variance3DPropDialog. DiffusionPropDialog. WriterPropDialog. ThresholdPropDialog «interface» IFilter. Reader Filter. Variance3D. Writer Viewer. Diffusion. Convolve Median. Sobel Threshold. Figura 15. Diagrama de clases implementado en AIDA.. Además de las clases señaladas anteriormente, en la gráfica anterior se destacan las clases GraphWindow2, que reemplaza a GraphWindow en VGJ; XMLBridge y HelpViewer. La razón para el cambio de nombre en GraphWindow2 es que en AIDA se cambió totalmente la clase GraphWindow pero se conservó la clase original porque hay funcionalidad que se podría aprovechar en una segunda iteración en el desarrollo. XMLBridge sirve para abstraer la lógica de guardar y cargar una tubería en formato XML. Aunque estas funciones se hubieran podido incluir en otras clases, se decidió crear XMLBridge para facilitar la lectura del código en el futuro (Fig. 16)..

(21) XMLBridge +loadFile() +writeFile(). Figura 16. XMLBridge. Clase encargada de leer y escribir una tubería en formato XML.. Lo mismo sucede con HelpViewer, una clase que abstrae la complejidad de leer un archivo en XML que contiene la dirección en la que se encuentran las páginas de ayuda para cada función y la creación de una ventana del navegador para ver la ayuda. HelpViewer está implementado utilizando el patrón Singleton. Para ver más información sobre el patrón Singleton ir a http://www.castle-cadenza.demon.co.uk/single.htm (Fig. 17). gui::HelpViewer -applet -document -instance +getInstance() +mostrarAyuda() +setApplet(). Figura 17. HelpViewer. Clase que abre una instancia del navegador, direccionado a la página de ayuda solicitada.. 3.3.. Implementación. El desarrollo de AIDA fue hecho utilizando JBuilder Foundation X como ambiente integrado de desarrollo. Esto aceleró el proceso de desarrollo pero generó conflictos con el código original de VGJ escrito en una versión de Java diferente a la que maneja JBuilderX. El conflicto consiste en que JBuilder genera automáticamente la mayoría del código de interfaz que se necesita al desarrollar una aplicación, permitiendo al programador concentrarse en la funcionalidad que quiere poner en la interfaz sin preocuparse por escribir el código que la implementa. Desarrollando AIDA se intentó utilizar JBuilder para modificar la interfaz gráfica, pero JBuilder no entendía el código de VGJ por la forma en la que estaba escrito. Por eso fue necesario diseñar la interfaz desde ceros y así aprovechar las facilidades de JBuilder..

(22) 4. Resultados La aplicación obtenida cumple con los conceptos definidos inicialmente como: - Manejo de la tubería. - Actualización automática de la información. - Ayuda integrada en la aplicación. - Extensibilidad al utilizar las librerías de VTK para modificar los datos y no para administrar el flujo en la tubería. - Aplicación Web. AIDA permite al usuario aplicar filtros sucesivos a una imagen e ir visualizando los efectos en los puntos que sean de interés. Eso representa el logro de un objetivo importante planteado al comienzo y una diferencia fundamental entre AIDA y otras aplicaciones del mismo campo (Fig. 18).. Figura 18. AIDA. Captura de pantalla con una Tubería de Procesamiento en la que se ve el efecto progresivo de los algoritmos sobre la imagen..

(23) En la figura 19 se puede ver el enlace con el manual de uso de la aplicación, otro de los objetivos planteados inicialmente.. Figura 19. Ventana de propiedades con el enlace a la ayuda en azul.. 4.1.. Defectos detectados. Hasta ahora, se han detectado los siguientes defectos en el código:: - Filtro Sobel genera un error. - Imágenes temporales no se borran: La implementación de los visualizadores genera imágenes temporales en la carpeta tmp en el directorio donde está instalada la aplicación. Cuando se abre la aplicación, ésta tiene código que borra las imágenes que estén en esa carpeta, sin embargo, en algunos computadores no funciona como debería. - Error al abrir o guardar imágenes: Las ventanas de propiedades de los nodos Writer y Reader ofrecen la posibilidad de navegar las carpetas de Windows para buscar el archivo que se quiere modificar. En ocasiones la aplicación no puede abrir la imagen seleccionada o guarda la imagen en un sitio diferente al seleccionado.. 4.2.. Trabajo futuro. En una siguiente iteración del desarrollo se debería revisar lo siguiente: - Implementar funcionalidad de Rehacer/Deshacer. - Mejorar la funcionalidad de actualización de la tubería para que pueda manejar filtros binarios y ciclos. - Implementar nuevos filtros. - Revisar la aplicación para eliminar código legado de VGJ que no se está utilizando. - Crear un instalador automático de la aplicación..

(24) 5. Conclusiones El diseño de la aplicación y la utilización de VGJ como base del desarrollo ayudaron a obtener un desarrollo satisfactorio. Sin embargo, el tiempo de desarrollo no fue suficiente para lograr una aplicación madura, es necesario iterar en el proceso de desarrollo para eliminar defectos, evolucionar el diseño y pensar en ampliar la funcionalidad. Aunque VTK tiene librerías ampliamente probadas en lenguajes como Tlc/tk, no existen buenas referencias ni ejemplos de utilización en Java. Durante el desarrollo se encontraron errores imposibles de resolver que fue necesario evitar dándole rodeos al problema. El inconveniente con VTK es que la implementación está en C++ y por eso la causa de los errores no se puede investigar desde Java. Durante el diseño se hicieron simplificaciones que aceleraron el proceso de desarrollo de esta versión pero que hay que revisar en el futuro y que aumentan la complejidad de la aplicación. Dos de estas simplificaciones son: primero, el grafo no contiene ciclos y segundo, los filtros reciben una entrada y entregan una salida. En aplicaciones sencillas esto se cumple, pero muy pronto aparecerá el requerimiento de poder procesar grafos más complejos. Se concluye que simplificar el problema fue acertado durante el diseño, pero se debió considerar con más calma durante el análisis para tener una opinión más objetiva de la calidad del diseño. En el desarrollo de una aplicación de calidad empresarial se necesita, además de tiempo, equipos de personas que aporten diferentes perspectivas durante las etapas iniciales del proceso de desarrollo y vayan documentando las ideas y las decisiones. Las ideas porque a veces en los procesos se vuelve sobre ideas que ya se habían desechado en favor de otras y se pierde tiempo valioso. Las decisiones porque en el diseño se debe plasmar cada decisión hecha durante el análisis. Un programa es inicialmente una idea en la mente de varias personas, cada una tiene su propia versión, es útil hacer diagramas de la interfaz de usuario para ir unificando la imagen de todos. Finalmente, las pruebas y las iteraciones en el proceso de desarrollo son la única forma de obtener un software de calidad, que sea de utilidad para los usuarios. Es muy difícil decir que un programa está libre de errores si no se le pone a prueba tanto en escenarios planeados como aleatorios, en los que los usuarios estén involucrados y aporten sus ideas de vuelta al proceso..

(25) 6. Bibliografía [1]. http://www.creatis.insa-lyon.fr/~libido. [2]. Alvaro H. Galvis Panqueva. Ingeniería de software educativo, Ediciones Uniandes. 359 p., 1992. [3]. http://cmap.ihmc.us/.. [4]. http://ww.vtk.org/. [5]. http://support.microsoft.com/default.aspx?scid=kb;en-us;87934.. [6]. http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html. [7]. http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/cr yptpki.mspx#XSLTsection124121120120. [8]. http://developer.netscape.com/docs/manuals/security/pkin/contents.htm#1047709. [9]. http://cmap.coginst.uwf.edu/info/. [10]. http://www.nist.gov/dads/HTML/graph.html. [11]. http://www.eng.auburn.edu/department/cse/research/graph_drawing/graph_drawing. html. [12]. http://www.eng.auburn.edu/department/cse/research/graph_drawing/COPYING. [13]. http://vtk.org/pdf/dioot.pdf.

(26)