Itk y vtk: ingeniería inversa y análisis de arquitectura pipeline
Yüklə 125,12 Kb.
|
- Bu səhifədəki naviqasiya:
- Descripción de la Solución
- Investigación de Herramientas de Ingeniería Inversa
- Investigación de la Librería VTK e ITK
- Investigación de herramientas para realizar prototipo
- Análisis de los componentes principales de VTK y sus relaciones
- Análisis de los componentes principales de ITK y sus relaciones
- Elaboración de Casos de Uso para el Prototipo
- Elaboración de los Requerimientos
- Elaboración de Prototipo
JustificaciónHerramientas de visualización y procesamiento de imágenes son muchas, solo por mencionar algunas se encuentras las ya detalladas en el Estado del Arte, las cuales son MIPAV, CreaTools, MITK, VolView y Khoros. La mayoría de estas están enfocadas en proveer un medio para el análisis de datos médicos y su procesamiento, y de esta manera obtener un resultado fácil de interpretar que sería la visualización de estos datos como imágenes. Por lo tanto si se desea realizar este procesamiento éstos softwares hacen uso de una estructura de tubos y filtros o pipelines en donde los datos pasan por un sistema de tuberías compuesto por filtros que procesan la información y pasan su información al siguiente filtro y así sucesivamente, hasta obtener la imagen o resultado esperado. La estructura de pipeline que usan la mayor parte de los sistemas especificados son los que proveen las librerías VTK y ITK, ya que éstas ya tienen los filtros desarrollados y al mismo tiempo el mecanismo para conectarlos. Sin embargo se requiere de mucho conocimiento en programación para poder utilizar estas herramientas, y darle un mayor provecho para generar nuevos algoritmos de procesamiento. Al mismo tiempo, aquellas personas que se encargan en procesar imágenes médicas no son experto en programación, y por lo tanto se dificulta la creación de estos nuevos algoritmos. Es así como, al entender el funcionamiento de las librerías ITK y VTKj se puede dar la posibilidad de crear nuevas herramientas para personas con menor conocimiento en programación, que permitan la construcción de nuevos algoritmos. Por lo tanto, al realizar un análisis de los elementos que hacen parte de la arquitectura de los toolkits VTK y ITK se logra generar conocimiento que permita el desarrollo de nuevos algoritmos o flujos de procesamientos de imágenes, y de esta manera brindarle, en un futuro, más herramientas a los médicos al momento de realizar un diagnóstico o estudiar el cuerpo humano. Originalmente se había redactado en la Propuesta del Trabajo de Grado que se realizaría la reingeniería de el framework Creatools, lo cuál incluía un análisis de las librerías que la componen que son las mencionadas VTK y ITK, junto con la ingeniera Monica Espinosa. Sin embargo la ingeniera se le presentó la oportunidad de viajar a Francia a terminar la carrera y por lo tanto el alcance del trabajo de grado se acorto a sólo la reingeniría de las librerías para que el alcance del trabajo fuese más realista teniendo en cuenta en que solo iba a ser realizado por una persona.
En esta primera etapa del proyecto se tomó como prioridad la investigación de las herramientas a utilizar así como el de las librerías para establecer las bases de las siguientes dos etapas. De esta forma, se inició con la investigación de la Herramienta de Ingeniería Inversa que luego se utilizaría para investigar los cimientos de los toolkits y al mismo tiempo se realizó una contextualización sobre las librerías. Luego escogida la herramienta se continuó con la investigación de los toolkits, esta vez haciendo uso de la herramienta escogida, y paralelamente se inició la investigación de una herramienta de desarrollo para la realización del prototipo.
Al comienzo se contempló la idea de realizar manualmente un diagrama de herencia entre los componentes de las librerías haciendo uso de una herramienta para realizar grafos, ya que las herramientas de ingeniería inversa no son completamente exactas al momento de generar un diagrama de abstracción del código. Además, de esta manera se puede llegar a una mejor comprensión de las clases que contiene la librería. Por lo tanto se realizó un diagrama de todas las clases de VTK en un programa de modelamiento de grafos para Mac OSX llamado OmniGraffle (el cuál fue escogido ya que ya tenía conocimiento de la herramienta al usarlo en trabajos previos). Para realizar este diagrama se tomó como referencia la documentación del código del toolkit que se encuentra en el siguiente enlace: http://www.vtk.org/doc/nightly/html/annotated.html, y se miraba en los diagramas, que cada clase provee, cuáles eran las clases de las que esta misma heredaba, y por lo tanto se hacía en vinculo desde la clase actual hacia la que ésta heredaba. Un ejemplo del diagrama de herencia de una clase de la documentación se puede ver en la siguiente imagen: 
Figura : Diagrama de Herencia de la clase vtkAbstractElectronicData[57] La figura muestra el diagrama de herencia de la clase vtkAbstractElectronicData, que como se puede ver hereda de la clase vtkDataObject, y que además las clases vtkOpenQubeElectronicData y vtkProgrammableElectronicData heredan de esta. Sin embargo, y como se esperaba, el trabajo de ir clase por clase y hacer el diagrama manualmente es muy tedioso, y la cantidad de clases y vínculos muy grande, por lo que se demoró la construcción de este diagrama alrededor de entre tres semanas y un mes. Claro esta, que como se entendía que el proceso sería largo, se realizó antes del comienzo del semestre. A partir de la experiencia de la realización de este diagrama se logró una mejor comprensión de las clases de VTK, especialmente de cuáles son las principales de las que la mayoría hereda, en donde se encontró que la mayor parte en la librería VTK hereda de la clase vtkObject. Teniendo en cuenta del trabajo tan extenuante que fue realizar el primer diagrama, y entendiendo que el tiempo que se dispone para la realización del proyecto es corto, se tomó la decisión de usar una herramienta de ingeniería inversa para el análisis del toolkit ITK. Por lo tanto se realizó una búsqueda de herramientas gratuitas, o en su defecto que estuvieran disponibles en la Universidad Javeriana, que ya previamente tuviera instalado, o que permitieran su uso durante un plazo determinado, para fijar una meta realista ya que la mayoría de estas herramientas al ser pagas no es posible tener acceso a ellas. Por lo tanto se llegaron a contemplar las siguientes:
Es una herramienta para la creación de diagramas CRUD, UML, Diagramas de Requerimientos, Mapas Mentales, Diagramas de Flujo, Diagramas ER, entre otros, y que aunque no es gratuita, esta herramienta permite su uso durante 30 días gratis. Además provee la opción de realizar un proceso de ingeniería inversa a código de C++ pero para poder realizar esto primero se debe exportar el código a XML usando un plug-in de Doxygen. Luego se importa el XML a la herramienta y se hace click derecho donde muestra una opción llamada Auto Create Class Diagram. Al realizar este proceso con la librería de ITK el resultado fue pobre ya que la cantidad de clases que se generaron y la información provista fue significativamente poca. Por lo tanto, y aunque se generaron los diagramas, se descartó esta herramienta.
StarUML es una herramienta gratuita que permite la creación de diagramas UML y MDA y cuyo código es compatible tanto con C++ como con Java. Para realizar ingeniería inversa simplemente se hace clic donde dice “Tools”, luego en el menú desplegado se hace clic en el lenguaje de programación del código fuente que en esta caso era C++, y se elije la carpeta raíz del código. Este proceso generó un diagrama con todas las clases de ITK junto con los nombres de sus atributos y sus métodos.[9]
Es un software pago desarrollado por SparxSystems que permite modelar, diseñar, simular, prototipar, construir, probar, manejar y trazar software, disponible solo para Windows[]. En este caso se realiza la ingeniería inversa escogiendo un modelo de diagrama que en esta caso se eligió un Diagrama de Clases, y encima de este modelo se hace clic derecho, luego del menú desplegable se hace clic en “Ingeniería de Códgo” y luego en “Importar directorio de Código Fuente”, y por último se elige el directorio del proyecto al que se le va a realizar la ingeniería inversa. El proceso para la librería, a diferencia del de Atah y StarUML que se terminó el mismo día, demoró una semana completa en realizarse, y además de esto al abrir el diagrama de clases generado para itk sale error de “Invalid Operation” o en su defecto el programa No Responde. Sin embargo EA realizó otros diagramas que sí se pueden abrir como por ejemplo el del Sistema.
Para lograr un análisis de un toollkit es necesario entender primero cuál es el propósito de este y de qué se trata. Por lo tanto se realizó una contextualización sobre las librerías de VTK e ITK buscando información, artículos, y herramientas asociadas.
Teniendo en cuenta que la información que se vaya a obtener de la investigación tiene como propósito ser usada para la generación de nuevos sistemas de procesamiento de imágenes, se propone la creación de un plugin o interfaz no robusta que use las clases e información encontrado. Por lo tanto se realizó una investigación sobre la herramienta adecuada para realizar la interfaz.
FLTK, o “fulltick”, es un toolkit para GUI’s multiplataforma de C++, que provee funcionalidades para la creación de interfaces de usuario incluyendo gráficos en 3D a través de OpenGL. Además incluye un editor gráfico llamado “The Fast Light User Interface Designer”, o FLUID[2], que permite la creación de aplicaciones a partir de la librería FLTK de manera más rápida ya que no es necesario conocer el nombre de todas las clases de FLTK para crearlo. En la siguiente imagen se puede ver el editor de Widgets de FLUID: 
Figura : FLUID [21] Esta herramienta no fue la elegida ya que en mis experiencias pasadas con la librería no fue posible la instalación de FLUID en Windows por lo cual tocó programar manualmente en C++ la interfaz lo cual es algo tedioso, especialmente si el proyecto a realizar es a corto tiempo, y también por que realizar un diseño en donde los elementos de la interfaz estén en el lugar adecuado para que sea cómodo para el usuario final de ver se vuelve complicado.
Es una librería multiplataforma, gratis y open-source, desarrollada en C++ y que permite la creación de aplicaciones, la cual hace uso del API nativo de la plataforma en la que se esta ejecutando lo que permite que las aplicaciones se vean de la misma forma de las aplicaciones nativas. Esta herramienta no fue elegida por la falta de experiencia con la misma, y además tomando en cuenta que no ofrece un editor del mismo que permita el rápido aprendizaje y uso del mismo.
Es una aplicación y framework multiplataforma de Interfaces de Usuarios para desarrolladores que usan C++ o QML. La IDE para desarrollo es QT Creador[37], el cuál incluye un editor gráfico para la creación de interfaces a través de QT Designer, aunque al mismo tiempo brinda la posibilidad de realizar la interfaz sin el uso de este, a través del código. A continuación se puede ver una imagen de una simple interfaz de una aplicación realizada en QT Designer de QT Creator: 
Figura :QT Designer en QT Creator[37] La razón por la que se eligió esta aplicación para la realización del prototipo es por la facilidad en el diseño de la interfaz gracias a la herramienta de QT Designer que agiliza el proceso de diseño, además por que tuve la oportunidad de conocer y trabajar con esta herramienta anteriormente lo que acorta la curva de aprendizaje de la herramienta.
Como se explicó anteriormente se realizó un diagrama de herencia de todas las clases de VTK y se identificaron las clases base y de las que heredan la gran parte de los objetos. A partir de la identificación de las mismas se pasó a leer y comprender la documentación del código asociado a las clases para poder empezar a comprender los métodos asociados y demás clases con respecto a la creación y ejecución de un pipeline en este toolkit. La arquitectura de tubos y filtros, o “pipeline”, de esta librería se basa en tres objetos del cual los filtros o datos heredan las funciones principales que conciernen el manejo de la información y los algoritmos del pipeline: vtkDataObject: Son los objetos que almacenan los datos que se generan cuando se procesan los filtros, y se manejan como inputs(datos de entrada) y outputs(datos de salida); de tal manera que el o los datos que genera un filtro como output se convierte en el input del siguiente.[45] vtkAlgorithm: Clase base de donde heredan los filtros que reciben como parámetro uno o más inputs para procesar, y a partir de este, generar uno o varios outputs.[45] vtkExecutive: Este objeto provee la lógica del manejo de los tubos y filtros, esto incluye principalmente la manera en cómo se conectan los algoritmos y cómo se ejecuta el pipeline. De tal manera se le asigna a este objeto un algoritmo al cual va a manejar, y al mismo tiempo los apuntadores a los outputs que este algoritmo necesita como input, y retiene la información de los outputs que este mismo genera. Por lo tanto en el pipeline cada algoritmo es manejado por un vtkExecutive, que se comunica con otros ejecutivos para generar en sí el pipeline.[45] Como se puede observar, el algoritmo y los datos no tienen información ni manejo del pipeline, sino que lo realiza un tercero: el ejecutivo. Esto no fue así siempre, pero se cambió para poder disminuir la complejidad y al mismo tiempo aumentar la flexibilidad de la arquitectura[56]. Otro de los cambios que se introdujeron a partir de la versión VTK 5 fue el del manejo de la meta-data de los objetos de datos producidos por los algoritmos, ya que ahora esta no se almacena en vtkDataObject en sí, sino que son representados por el objeto vtkInformation. Por lo tanto, el ejecutivo mantiene dos vectores de objetos de información (vtkInformationVector es un objeto que almacena uno o más vtkInformation[44]), el de los inputs, y de outputs del algoritmo. [55] [56]. A continuación se puede apreciar una representación de cómo se ejecuta el pipeline:
Figura : Diagrama de Secuencia de la ejecución de un pipeline en VTK En el diagrama anterior se puede apreciar que la función principal de los ejecutivos se llama ProcessRequest. Esta función como su nombre lo indica en ingles, procesa una petición, y por lo tanto lo que hace es que mira la información de sus vectores de input y de output; si el input en alguno de los algoritmos esta desactualizado, dentro de ProcessRequest se llama a la función CallAlgorithm que tiene como objetivo pedirle al filtro que le proporciona el input que se debe actualizar (por lo tanto llama a la función ProcessRequest de esta), y si esta también necesita input del anterior llama al que le sigue y así simultáneamente hasta llegar al final del pipeline o a un punto en que la información este actualizada. Para saber si la información generada por un filtro está actualizada se compara la meta-data generada por un filtro con la del filtro que produce los inputs del mismo, si esta información de los inputs del algoritmo datan de un tiempo después que las del output generado por él mismo, significa que el output esta desactualizado y por lo tanto ese filtro se debe procesar de nuevo.
Como se había mencionado, el funcionamiento del pipeline de VTK cambió desde su versión VTK5, pero antes de esto el pipeline era controlado por sus objetos de datos y algoritmos. La arquitectura del pipeline de ITK está inspirada en la manera en cómo funcionaba VTK anteriormente [44], por lo tanto se puede apreciar una diferencia notoria entre las dos librerías, y es que ITK no hace uso de objetos ejecutivos, sino que tiene como base dos objetos: DataObject: Al igual que vtkDataObject, es un objeto que representa y provee acceso a datos.[24] ProcessObject: Este objeto provee la base para los filtros que procesan los objetos DataObject, al igual que vtkAlgorithm , para generar nuevos objetos de datos. Estos dos objetos son los que se encargan a la vez de la ejecución del pipeline. Para conectar dos algoritmos sencillamente se toma el DataObject que genera un filtro como output y se le asigna a otro filtro como input para su propio algoritmo. Un filtro puede tener uno o muchos inputs, o puede generar su propio input leyendo un archivo, y puede generar uno o más outputs que servirán para uno o más filtros como input. Al igual que en VTK, estas conexiones se manejan con apuntadores entre un filtro y otro al objeto de datos entre ellos. Ahora bien, para que se ejecute el pipeline se debe generar una actualización, y por lo tanto un llamado a la función Update(), el cual produce en el pipeline tres diferentes pases.
Se puede apreciar el flujo de estos pasos en el siguiente diagrama de secuencia, 
Figura :Diagrama de secuencia de la ejecución de un pipeline en ITK, el cuál fue adaptado de la Figura 9.7 de la documentación encontrada en el siguiente enlace: http://aosabook.org/en/itk.html
Se elaboraron Casos de Uso para modelar la interacción entre el prototipo y el usuario. Por lo tanto se realizó un diagrama de Casos de Uso en dónde se identificaron las interacciones entre el usuario y el sistema, el cuál se puede ver en la imagen a continuación; y a partir de este diagrama se realizó una Especificación de los Casos de Uso en donde se detallan cada uno de estos el cuál se encuentra en el Anexo 1. 
Figura : Diagrama de Casos de Uso
A partir de la identificación de los Casos de Uso se elaboró una lista y especificación de requerimientos que describen las funcionalidades que debe contener el prototipo. Estos requerimientos y su respectivo detalle se encuentra en el Anexo 2.
Luego de la realización del análisis del funcionamiento del prototipo a partir de los Casos de Uso y los Requerimientos se elaboraron Mockups los cuales muestran un diseño de cómo se debe ver la interfaz y de esta manera aclarar todas las ventanas que debe tener el prototipo y sus componentes para garantizar que el usuario tenga acceso a todas las funcionalidades de una manera sencilla. El resultado fueron las siguientes imágenes que permiten dar una idea de cómo se verá le producto final: 
Figura : Ventana Principal 
Figura : Ventana de Vista Simultanea – Se puede visualizar simultáneamente y del mismo tamaño las cuatro vistas del resultado del pipeline ejecutado. 
Figura : Ventana de Vista Especifica - Se elije haciendo doble clic la vista que se desea ver específicamente el cual se va a visualizar en una tamaño mayor que con respecto a las otras tres. 
Figura : Vista del Filtro - Al hacer doble clic sobre un filtro se muestran las variables, templates inputs y outputs que este mismo posee, y desde esta misma ventana se pueden modificar.
Como se definió anteriormente la herramienta elegida para realizar el prototipo es QT, desde el IDE QT Creator. A partir de los Casos de Uso, Requerimientos, y Mockups se tenía una idea muy clara de lo que se debía realizar por lo tanto luego de tener estas especificaciones definidas se comenzó la realización del código, el cual se rigió por el paradigma Orientado a Objetos. Por lo tanto para lograr esto se hizo una investigación paralelamente de cuáles eran los Widgets, clases, y métodos de QT necesarios conocer para realizar las funcionalidades requeridas. En la experiencia previa con esta herramienta aprendí que la curva de aprendizaje de esta herramienta era considerablemente larga y efectivamente esto se hizo presente durante la construcción del prototipo. QT provee una gran cantidad de ejemplos de aplicaciones sencillas en donde se hace uso de todas las funcionalidades que posee y esto fue muy útil al realizar la investigación de las clases que provee y cómo funcionan. Así mismo, se empezó a realizar el prototipo desde los requerimientos de mayor prioridad para asegurar que estos quedaran realizados en una etapa temprana; aun así, las funcionalidades que más tiempo tomo realizar fueron las relacionadas con el editor de nodos.
Al tener definidas todas las clases y funcionalidades del prototipo se realizó un Diagrama de clases que define tanto los atributos de estos, sus métodos, y relación con las otras clases. A partir de este diagrama se realizó una explicación de cada una de estas clases, haciendo énfasis en los métodos que contiene, para permitir en un futuro que personas distintas, si así lo requieren puedan leer, e incluso modificar el código. Esta documentación se encuentra en el Anexo 3. 
Figura :Diagrama de Clases
|
