Desarrollo de una interfaz dinámica basada en descriptores

Texto completo

(1)DESARROLLO DE UNA INTERFAZ DINAMICA BASADA EN DESCRIPTORES. JULIAN EDUARDO GRIJALBA FACUNDO. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION BOGOTA D.C. 2006.

(2) DESARROLLO DE UNA INTERFAZ DINAMICA BASADA EN DESCRIPTORES. JULIAN EDUARDO GRIJALBA FACUNDO. Trabajo de Grado para optar al título de Ingeniero de Sistemas y Computación. Asesor: CLAUDIA LUCIA JIMENEZ GUARIN. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION BOGOTA D.C. 2006.

(3) AGRADECIMIENTOS. A un ángel, mi madre, la cual con su dulzura y sabiduría, aportó en mí, las fuerzas necesaria para construir y lograr este sueño, y mi padre, un ser paciente, sabio, e incondicional, él cual , me enseño la verdadera esencia del trabajo. A ellos, y a quienes me han apoyado en el logro de este sueño, mis infinitas gracias..

(4) CONTENIDO. 1. INTRODUCCIÓN ................................................................................................................................... 1. 2. OBJETIVOS........................................................................................................................................... 3 2.1 OBJETIVOS GENERALES ............................................................................................................. 3 2.2 OBJETIVOS ESPECIFICOS ........................................................................................................... 3. 3. ANTECEDENTES Y CONTEXTO ......................................................................................................... 4. 4. ESTRATEGIA DE SOLUCIÓN .............................................................................................................. 6 4.1 CARACTERISTICA DE LOS DESCRIPTORES ............................................................................. 6. 4.2 INVESTIGACION Y SELECCIÓN DE HERRAMIENTA PARA LA GENERACION DE WWWWGRAFICOSCARACTERISTICA DE LOS DESCRIPTORES.......................................................... 8 4.3 SELECCIÓN DE HERRAMIENTA PARA LA CONSTRUCCION DE INTERFACES …………GRAFICAS ..................................................................................................................................... 9 5. DESCRIPCIÓN DE LA SOLUCIÓN .................................................................................................... 11 5.1 DEFINICION DE LOS DESCRIPTORES PARA LA APLICACIÓN.............................................. 11 5.2 DEFINICION DEL AMBIENTE DE DESARROLLO ...................................................................... 15 5.2.1 LENGUAJE.......................................................................................................................... 15 5.2.2 AMBIENTE DE PROGRAMACION .................................................................................... 15 5.3 DESCRIPCION DE LA ARQUITECTURA DE LA APLICACION ................................................. 16 5.3.1 MODELO DEL MUNDO....................................................................................................... 16 5.3.2 MODELO Y DESCRIPCION DEL DISEÑO ........................................................................ 17 5.3.3 ARQUITECTURA DEL SOFTWARE DE INTERFAZ.......................................................... 24 5.3.4 DIAGRAMA DE SECUENCIA DE INICIO DE LA APLICACIÓN ....................................... 25. 6. ANALISIS DE RESULTADOS............................................................................................................. 26 6.1 INTRODUCIR INFORMACIÓN...................................................................................................... 26 6.2 VISUALIZACIÓN DE INFORMACIÓN ......................................................................................... 35 6.3 CONSULTA DE INFORMACIÓN ................................................................................................. 38. 7. CONCLUSIONES ................................................................................................................................ 45.

(5) 8. BIBLIOGRAFIA .................................................................................................................................. 46. 9. ANEXOS .............................................................................................................................................. 48 9.1. DEFINICIÓN DESCRIPTOR PARA EXÁMENES ..................................................................... 48. 9.2. DESCRIPTOR DE EXÁMENES BASADO EN LA DEFINICIÓN DEL ANEXO 1...................... 59. 9.3. DEFINICIÓN DESCRIPTOR PARA CONSULTAS ................................................................... 52. 9.4. DESCRIPTOR DE CONSULTAS BASADO EN LA DEFINICIÓN DEL ANEXO 3 .................. 53.

(6) 1. INTRODUCCIÓN. La universidad de los Andes, actualmente entre sus líneas de investigación y desarrollo tiene un grupo en el área de la bioingeniería; este grupo se encuentra formado por ingenieros mecánicos, ingenieros de sistemas en conjunto con médicos del hospital San Ignacio de Bogotá. Este grupo de investigación actualmente esta desarrollando el proyecto CAROTIDA II, el cual tiene como objetivo principal: Estudiar el flujo sanguíneo y los esfuerzos en las paredes vasculares, al igual que las propiedades mecánicas de la sangre y paredes de vasos sanguíneos en condiciona normales fisiologías y patológicas, mediante modelos matemáticos y computacionales [1]. Actualmente el grupo de investigación posee una herramienta de software, desarrollada en la Universidad de los Andes denominada Sistema de Apoyo al diagnóstico y Seguimiento de Enfermedades SASE[2], como apoyo al registro de los resultados de investigación de la primera etapa, Carótida 1. El problema de este software surge debido a que esta área, por ser de carácter investigativo, constantemente se encuentra en evolución, encontrando nuevos hallazgos y demandando nuevas tendencias de información. Son entre estas: nuevos campos de datos, nuevos estilos de exámenes, nuevas maneras de consulta y visualización de la información, entre otros. Las anteriores demandas no son cubiertas en su totalidad por el software SASE[2], debido a que este software fue enfocado y acoplado con la primera fase del proyecto, en donde se deseaba guardar una información alfa-numérica, sin considerar requerimientos de interpretación y visualización grafica de esta, y menos aun en la elaboración de complejas consultas para obtener datos relevantes para el proyecto. El software SASE[2] cumple con las funciones de representación y manipulación de información, sin embargo debido a los nuevos hallazgos investigativos, esta herramienta no brinda la posibilidad de adaptarse a las necesidades del usuario. Además de esto, las consultas de información deben ser dinámicas, dado que estas no están claramente definidas y resultan del proceso de análisis de los hallazgos en el proyecto. Esto genera inconvenientes al grupo investigador ya que este equipo debe adaptarse a las limitantes del software, perdiendo información vital para ellos, o modificando el código fuente del software (código base) para que pueda manipular la nueva información. La modificación de SASE[2], genera altos costos de mantenimiento que al final no solucionan el problema, ya que por cada nuevo tipo de información que se desea agregar, se necesitaría nuevamente realizarle mantenimiento al software, trasladándonos al problema inicial; esto hace que o perdamos información o mantenemos el software a unos costos in calculados. Este problema de iteración, ha sido un inconveniente para el manejo de la información entre los distintos campos del área investigativa, ya que no se cuenta con un sistema que pueda integrar la información actual que poseen, y menos aún, un software que pueda adaptarse contínuamente en el tiempo de forma automática a la información propuesta por este grupo. La herramienta a desarrollar, tiene como objetivo principal la independencia y desacople total entre el software desarrollado y la información requerida por el grupo de expertos, esto con el fin de poder modificar una de las dos partes, sin tener ningún inconveniente con la otra. Al poder independizar el software de la información que debe manipular, se dará un gran paso, ya que se rompe con el paradigma de que el software se construye solo en base a las necesidades de información que sean planteadas en el proyecto, y podrá generar como beneficios una adaptabilidad de software a las necesidades constantes de una información cambiante, con unos costos de mantenimiento iguales a cero. Debido a las exigencias del proyecto Carótida II, la herramienta desarrollada será el perfecto apoyo para un grupo de investigación, como este; por las grandes ventajas de adaptabilidad a las exigencias continuas de cambios en la información, y al ofrecimiento de nuevos servicios consulta y representación grafica de información alfa-numérica para facilitar, tanto el análisis como la comprensión, de la información.. 1.

(7) Sujeto a estos requisitos de independencia, y a la necesidad de comunicación entre la parte de datos y de software, se selecciona un estándar de representación de datos que ofrece ventajas en la manipulación de los mismos, como es el XML (Extensible Markup Lenguaje) en complemento con el formato de definición de archivos DTD (Document Type Definitions). Este software se integrará con una base de datos, la cual almacena la información que relevante para el proyecto. El desarrollo del módulo que se ocupa del control de la aplicación y del manejo de la base de datos no son parte de este trabajo aunque son fundamentales para el desarrollo íntegro del software. Este trabajo se centra en los aspectos de generación del módulo de interfaz del sistema, tanto en inserción y despliegue de la información, como en la generación dinámica de consultas. Este trabajo tiene los siguientes objetivos: 1. Permitir la generación de la interfaz gráfica de la aplicación de forma que permita la integración y adaptación del despliegue a la información definida por los expertos en diagnóstico. 2. Visualización de información representada en el sistema, tanto de forma alfanumérica como la generación de gráficos o despliegue multimedia con base en esta misma. 3. Generación dinámica de la interfaz de consultas complejas ad hoc, las cuales generan resultados gráficos o alfa-numéricos, que permiten estudiar correlaciones en la información registrada. La estrategia de solución adoptada en este trabajo, se basada en descriptores de información, los cuales fueron desarrollados en XML. Estos descriptores satisfacen la definición del documento (DTD) orientados al experto, y es el experto quien describe en esos documentos la información a manipular y sus características de visualización. En los anexos 1 y 3 se encuentran estos documentos en el estado definido por los expertos en el momento de publicación de este trabajo.. 2.

(8) 2. OBJETIVOS. 2.1. Objetivos Generales •. Proporcionar una aplicación adaptable a las necesidades continuas de información y modificación de datos, en el contexto de aplicaciones de registro de información diagnóstica, que tiene el grupo de Bioingeniería de la Universidad de los Andes.. •. La aplicación genera interfaces graficas según la información plasmada en el descriptor.. •. La aplicación por medio de su interfaz grafica, permitirá interactuar con una base de datos tanto para introducir información, como para visualizarla de forma alfa-numérica o grafica.. 2.2. Objetivos específicos •. Investigar y recolectar la mayor información factible utilizada por el equipo de bioingeniería para poder, de esta manera, generar una idea de cómo y que tipo de información es representada en los descriptores.. •. Investigar la tecnología más adecuada para la manipulación de archivos descriptores, la cual represente de forma adecuada la información para ser adoptada por el grupo de expertos. Esta debe aportar a la herramienta un excelente desempeño, a un consumo mínimo de memoria principal.. •. Investigar y seleccionar las herramientas de desarrollo mas apropiadas para la generación de elementos gráficos que permitan cambiar sus características de visualización de forma flexibles y en casos específicos, dinámicamente.. •. Investigar y seleccionar una arquitectura basada en descriptores para la generación flexible del mundo de la aplicación.. •. Analizar y concluir si es viable o no, el desarrollo de los nuevos módulos e implantación de la arquitectura seleccionada basada en descriptores en el software utilizado actualmente por el grupo de Bioingeniería.. •. Desarrollar una aplicación con una arquitectura estable para la generación dinámica de interfaces graficas basadas en descriptores. Esta arquitectura debe soportar la generación interfaces graficas adaptables para la entrada de datos y visualización alfa-numérica y/o representación grafica de la misma; además de generación dinámica de interfaces graficas para la consulta de la información.. 3.

(9) 3. ANTECEDENTES Y CONTEXTO. La aplicación SASE[2], esta definida en principio por una arquitectura de 3 capas, las cuales se distribuyen de la siguiente manera:. Figura 1 – Arquitectura general del sistema de apoyo al diagnóstico [2] Para el desarrollo del actual software, fue necesario analizar la aplicación SASE[2], para así, concluir si era posible modificar la aplicación y adaptarla a la nueva arquitectura propuesta o simplemente era más factible, dejarla a un lado y comenzar un nuevo desarrollo. Este análisis se sustento en la documentación de la tesis realizada para el desarrollo de SASE[2] y en el código base de la aplicación. Al estudiar la funcionalidad del programa cumple a cabalidad con los requerimientos específicos de la fase I de Carótida, sin embargo presenta problemas en el diseño de interacción con el usuario. Esto problemas surgen a causa de que la interfaz no posee un manejo intuitivo y despliega una gran cantidad de información en espacios reducidos. Al análisis el software se concluyo que la adaptabilidad del programa a las exigencias de nuevos esquemas de información es baja y es, en este estado donde el programa pierde su funcionalidad, ya que al no manejar y adaptarse a las nueva exigencias de información requerida, produce a medida del tiempo 4.

(10) una inoperatividad del sistema y necesidades de integración de estos requerimientos mediante la reconstrucción del software. Además la implantación de esta nueva arquitectura basada en descriptores, produciría excesivos gastos de recursos y tiempo, los cuales son muy escasos, además impondría ya no un reto de una nueva tecnología, si no del rediseño de un software. Después de examinar los anteriores puntos, e invertir un lapso de tiempo en implementación y entendimiento de esta aplicación, la decisión a seguir es desarrollar una aplicación, la cual se adapte de forma dinámica a los nuevos requerimientos de información y asuma una arquitectura basada en descriptores, la cual establezca módulos para la generación de interfaces adaptables a nuevos modelos de información y a la generación dinámica de consultas, además de poder interactuar con una base de datos y tenga la posibilidad de ser acoplado en un futuro, a esta aplicación. Para el desarrollo de esta nueva aplicación se siguen los estándares actuales de la Universidad de los Andes para la construcción de software. En estos estándares se establece claramente las estructuras correctas de manejo de carpetas en la implementación del proyecto, un manejo de documentación tanto en las clases desarrolladas, como en los documentos escritos relacionados a esta aplicación. En complemento a esto, se establecen arquitecturas basadas en las necesidades del negocio y se incorporan capas de información para separar de una forma clara y correcta, los diferentes niveles de datos que posee la aplicación.. 5.

(11) 4. ESTRATEGIA DE SOLUCIÓN. Se realizo una recolección de datos significantes, los cuales fueron base fundamental para definir claramente unos descriptores que tuvieran la capacidad de soportar las exigencias y modificaciones continuas de información realizadas, en un proceso investigativo. Se analizó el software actual manejado por el equipo de investigación, se hizo una actualización de tecnología, para evolucionarlo a plataformas Java – SDK 1.5, Tomcat 2.0 y MySQL 5.0 .Al concluir con la migración de tecnologías, el principal objetivo es solucionar los problemas de interfaces. En este proceso se concluyo, que integrar y desarrollar los módulos sobre la plataforma actual, generarían altos costos de personal y tiempo; siendo el desarrollo de un nuevo software el medio más factible para el acoplamiento de los nuevos requerimientos exigidos por el grupo de Bioingeniería. Para la implementación de este nuevo software fue necesario investigar y seleccionar tecnologías apropiadas para la manipulación de descriptores, además de seleccionar alternativas para la generación de interfaces graficas y graficas como barras, pies, curvas, series de tiempo y graficas de dispersión, las cuales son las más adecuadas para representación grafica de la información existente. Los descriptores con los cuales se construyo la aplicación tienen la capacidad de modelar la generación de una aplicación según la información que se encuentre representada en los mismos. Los beneficios del software de interpretar independientemente el descriptor y la información que posee en este, se logra independencia entre el software y la información representada en el mismo. 4.1. Características de los descriptores. El descriptor para la manipulación de exámenes, tienen restricciones las cuales son descritas a continuación: 1. Obligatorio: Describe si este campo debe tener o no información necesaria para ser introducido en la base de datos. Si este campo es obligatorio y no tiene información descrita por el usuario, el software generara una alerta para que este campo no este vacío. 2. tipocampo: Posee información esencial para el manejo de la información con la base de datos, ya que describe si el campo es texto, fecha, archivo, booleano, entero, real, entre otros tipos. 3. tipoValor: Un campo puede o no tener un tipo de valor, si no lo tiene será asumido como si fuera un atributo como una fecha o un texto. Si lo tiene, especifica información necesaria para la visualización de los campos de un examen. A continuación se describen cada uno de ellos: a. Rango: Un resultado puede estar en un rango de valores. Cada uno de los rangos tiene un significado y un color. En caso tal que el descriptor no tenga la información con los colores necesarios que representan cada significado, el software tiene la autonomía de generar unos colores en base a una paleta interna que maneja. b. Enumeración : Cada resultado tiene un significado especifico c.. Absoluto: Tiene unos limites tanto inferiores como superiores, en los cuales puede estar el resultado del examen. d. Serie: Describa una serie de valores x,y que son interpretados y graficados por medio de charts.. 6.

(12) 4. Placa: Este campo puede o no estar presente en el examen. Si se encuentra su manejo va a ser de la misma manera que un campo de examen, en donde están presentes campos como: obligatorio, ticocampo y tipovalor. Para el descriptor de consultas, tiene que facilitar generación dinámica de peticiones a la base de datos desde la interfaz grafica, en donde los resultados obtenidos, son desplegados como una visualización grafica o alfa-numérica según lo estipulado por el descriptor. Cada una de estas consultas tiene unos parámetros de entrada y de salida, en donde estos tienen como objetivo proveer la información necesaria para poder construir la consulta y mostrar la información solicitada por el usuario. El descriptor de consultas, tienen restricciones las cuales son descritas a continuación: Para los parámetros de entrada es el siguiente: 1. nombre_examen: Examen de donde se tomara la información. Para la base de datos es una tabla que existe. Este proporciona información para la construcción del “FROM” en la consulta. 2. campo_examen: campo del examen fuente de la información. Para la base de datos es un campo una tabla específica. Este proporciona información para la especificación del “WHERE” en la consulta. 3. tipo_consulta: Proporciona información para la construcción del “WHERE” en la consulta, en donde el parámetro introducido por el usuario va a ser mayor, menor, igual o un rango. Un ejemplo es que si la consulta del campo edad es el tipo mayor, entonces se generara un WHERE de este estilo : WHERE edad > valor introducido por el usuario. Para los parámetros de salida es el siguiente: 1.. tipo_resultado: Específica si la consulta genera un resultado “grafico” o de “valores”. El primero representa una grafica de dispersión y el segundo resultados alfa-numéricos.. 2. nombre_examen: Examen de donde se tomara la información. Para la base de datos es una tabla que existe. 3. campo_examen: campo del examen fuente de la información. Para la base de datos es un campo una tabla específica. Este proporciona información para la especificación del “SELECT” en la consulta.. 7.

(13) 4.2. Investigación y selección de la herramienta para la generación de gráficas. En esta etapa de investigación, se buscaron tecnologías graficas que pudieran ser utilizadas para el procesamiento y visualización de la información especificada, tanto en los descriptores XML, como en los resultados alfa-numéricos suministrados por la base de datos. Esta investigación, tiene una serie de requisitos para la elección de la herramienta, estos son las siguientes: 1. Licencia GNU, GPL o FREEWARE 2. Compatibilidad con la tecnología JAVA. 3. Graficas de alta calidad Nombre. Licencia. Fortalezas. Desventajas. Visualmining[12]. Copyright. Generación excelente de charts.. Licenciamiento. Integración con el lenguaje java. Licenciamiento. Big Faceless Graph Library[13]. Copyright. Generación excelente de charts. Integración con el lenguaje java. Su enfoque es mas hacia el entorno Web que al stand alone. Las graficas no son de buena calidad.. Ptplot[14]. GNU, GPL. Integración con el lenguaje java Existe poca documentación sobre la misma. KavaChart[15]. Chart2D[16]. Copyright. GNU, GPL. Integración con el lenguaje java.. Licenciamiento. Genera charts de alta calidad.. No maneja Charts en 3D. Integración con el lenguaje java. Las graficas no son de excelente calidad. No puede generar charts en 3D Las graficas no son de excelente calidad.. JChart[17]. GNU, GPL. Integración con el lenguaje java. 8.

(14) JOpenChart[18]. GNU, GPL. Integración con el lenguaje java. Las graficas no son de alta calidad. No genera charts en 3D. JFreeChart[11]. GNU, GPL. Integración con el lenguaje java. Ninguna. Genera charts en 3D. Después de hacer un análisis sobre cada una de las características de las herramientas encontradas en el mercado, se pudo concluir que la mejor de ellas, y la que mas se ajusta a los requerimientos exigidos es JFreeChart. Esta herramienta proporciona funcionalidades de creación de charts, facilitando la generación de gráficos con excelente calidad, en un menor tiempo de desarrollo.. 4.3. Selección de herramienta para la construcción de interfaces gráficas. En esta etapa, se realizó una comparación con las dos tecnologías mas usadas actualmente en la industria para la generación de entornos gráficos en las aplicaciones desarrolladas bajo Java. Con este fin se realizó una investigación de tecnologías Swing y SWT. Esta investigación se desea identificar las fortalezas y debilidades de cada una de estas tecnologías, y así poder seleccionar la más apropiada para los fines del proyecto actual.. SWING[3] Es un conjunto de herramientas para el manejo de interfaces gráficas en Java. Swing hace parte de la JFC (Java Foundation Classes). Es La referencia de interfaces gráficas para J2SE. Swing proporciona unos sofisticados componentes -alto nivel como son árboles, tablas y textos- para la generación de GUIs. Se encuentra implementada totalmente en Java. Es totalmente independiente de la plataforma y corre en todas de igual manera. Una gran ventaja es su característica llamada Look and Feel (mira y siente) la cual hace que la aplicación que utilice Swing, se vean o adapten según el sistema operativo en el que se corre. Esta ventaja ofrece una ofrece una adaptabilidad simple y automática, sin afectar en ningún momento el código base de la aplicación. Un inconveniente de SWING es que al ser implementada totalmente en JAVA, es necesario que siempre su código, sea interpretado por la Java Virtual Machine,; esto produce que sea sensiblemente más lento, a las librerías que utilizan el sistema de interfaces nativo del sistema operativo (SO).. 9.

(15) SWT (Standard Widget Toolkit) [4] Esta Liberia fue desarrollada por IBM como parte de la plataforma de Eclipse. Es una librería grafica y una interfaz de interacción integrada con el sistema nativo del sistema (especialmente en Windows, pero en Linux y Solaris también es soportado). A pesar de la integración con el sistema operativo (SO), SWT es un API independiente al SO. Siendo SWT como un delgada envoltura sobre el código nativo de interfaces en las que trabaja el SO. Al utilizar el manejo de interfaces gráficas nativo, esta librería logra unos tiempos de respuestas mucho más altos que SWING, ya que no es necesario de la interpretación siempre del código Java. La estrategia de diseño de esta librería esta enfocada en construcciones simples. SWT delega a el código nativo del SO, el manejo de simples interfaces como son etiquetas, listas, tablas, etc. mientras que emula con Java interfaces mas sofisticadas como es una barra de herramientas. Conclusión: SWING proporciona una gran cantidad de características, las cuales tienen una visualización muy elegante y además obtienen un nivel de mayor abstracción, convirtiéndose esto en la principal diferencia con SWT, ya que genera un desarrollo más fácil de complejas estructuras de interfaces gráficas en donde se manejan e integran gran cantidad de componentes diferentes. En general SWT es muy fácil de usar en desarrollos pequeños, donde la complejidad de las interfaces no sea muy alta, ya que entre mas aumente la complejidad de la GUI, el resultado con SWING es muchísimo mas fácil y mas flexible. Para nuestro objetivo, de generación de interfaces con componentes de alto nivel y sin necesidad de altos tiempos de respuesta, lo mas apropiado es seleccionar la librería SWING para el desarrollo de interfaces graficas en la aplicación.. 10.

(16) 5. DESCRIPCIÓN DE LA SOLUCIÓN. La solución actual planteada en esta tesis es darle independencia tanto al software como a la información que éste manipule, dando posibilidad que al no estar acoplado el software con la información, al modificarse el (los) descriptor(es) de la aplicación, estos cambios se verán reflejados en la interfaz grafica. A continuación se describe la solución construida en base a la estrategia presentada en el capitulo 4.. Tecnologías utilizadas en la implementación de la solución 5.1. Definición de los descriptores para la aplicación. Para los fines del desarrollo de la aplicación fue necesario hallar una arquitectura que fuera capaz de soportar la generación de una aplicación en base a unos descriptores de texto. Con este propósito, se investigaron las posibles alternativas para la seleccionar una solución acorde a las tecnologías actuales de punta. Al realizar esta investigación, se encontró en la industrial de software, un formato muy interesante y altamente utilizado para el manejo de texto, el cual es denominado XML (eXtensible Markup Language). Este formato establece unas reglas estrictas para el manejo de la información, y genera una serie de verificaciones que serán altamente utilizadas para poder identificar si existen o no errores en la creación de los descriptores. Al seleccionar el formato XML, como base fundamental para la definición de los descriptores, se integro con un formato para la definición del tipo del documento, denominada DTD (Document Type Definitions), para de esta forma crear unos descriptores robustos y confiables, los cuales serán el pilar fundamental, para el manejo e interpretación de la información contenida en ellos. Al integrar el descriptor con el DTD, podemos generar plantillas XML, las cuales facilitaran a los expertos la manipulación del XML y la introducción de datos al mismo. Actualmente se tienen dos descriptores, cada uno de ellos interpreta dos formas distintas de generación del las interfaces graficas. El primero denominada exámenes, es el encargo de proporcionar información al software para construir las interfaces graficas tanto en visualización de información como en entrada de la misma. Un ejemplo de se observa en la siguiente pagina.. 11.

(17) <Examenes> <Examen nombre="Paciente"> <campo nomcampo="Descripcion"> <descripcioncampo/> <obligatorio>si</obligatorio> <tipocampo>texto</tipocampo> </campo> <campo nomcampo="Fecha nacimiento"> <descripcioncampo/> <obligatorio>si</obligatorio> <tipocampo>fecha</tipocampo> </campo> <campo nomcampo="Genero"> <descripcioncampo/> <obligatorio>si</obligatorio> <tipocampo>booleano</tipocampo> <tipovalor> <enumeracion> <valores> <valor>0</valor> <significado>Femenino</significado> </valores> <valores> <valor>1</valor> <significado>Masculino</significado> </valores> </enumeracion> </tipovalor> </Examen> </ Examenes>. El descriptor de denominado exámenes puede manipular de uno a muchos exámenes a la vez, cada examen tiene sus propios campos, los cuales representan información de un examen o una información relevante para el mismo, como puede ser por ejemplo el sexo, edad, una fecha especifica entre otros. La descripción de restricciones en los campos de un examen se encuentran en el capitulo 4. En el anexo 2 se encuentra la descripción de la versión actual de este descriptor. En la interfaz grafica este descriptor reflejara, que por cada <Examen>, se despliega una pestaña, en el descriptor anterior, la pestaña tendra el nombre “paciente”. Para obtener una noción grafica de cómo estos campos se ven en el software final, remitirse al capitulo 6. Cada Campo del examen, se reflejara como un panel pequeño dentro de la pestaña, en el ejemplo anterior se desplegara la pestaña Paciente, con tres campos. Cada campo se desplegara de forma distinta ya que los dos primeros no tiene el campo <tipovalor>, lo que implica que son atributos, para tener noción de la diferencia entre un panel y un atributo, remitirse al capituló 6. Cuando los campos tiene un <tipovalor>, se pueden desplegar de diferentes formas en la interfaz. Cuando son de <tipovalor>, <enumeracion> o <rango>, generan unos paneles en donde el usuario puede seleccionar valores precisios; si este <tipovalor> es <absoluto> se despliega un panel, con información de los valores máximos y mínimos que pueden ser introducidos por el usuario. Para el manejo de los campos de <enumeracion>, se tendran que dar unos valores, los cuales tiene un valor y un signifcado, esto aportan la información necearia para generar graficos y para la información 12.

(18) que debe ser introducida en una posible base de datos, puede verse en el ejemplo anterior como se distribuye esta información . En el caso de <rango> a continuación se ilustrara con un fragmento de la definición final de examen, la cual se encuentra en el anexo 2. <campo nomcampo="Grado estenosis"> descripcioncampo/> <obligatorio>si</obligatorio> <tipocampo>entero</tipocampo> <tipovalor> <rango limINF="0" limSUP="100" ejeX="creatina" ejeY="creatina"> <valoresRango> <valorRango>50</valorRango> <significadoRango>Normal - No significativo</significadoRango> <colorRango>GREEN</colorRango> </valoresRango> <valoresRango> <valorRango>70</valorRango> <significadoRango>Estenosis leve</significadoRango> <colorRango>YELLOW</colorRango> </valoresRango> <valoresRango> <valorRango>99</valorRango> <significadoRango>Estenosis pre-oclusiva</significadoRango> <colorRango>RED</colorRango> </valoresRango> </rango> </campo> En esta descripción se tiene un <tipovalor> que es <rango>, en donde este tiene unos limites para la validación de la información introducida en el descriptor. Estos limites son inferior “limINF”, superior “limSUP”, y una descripción de cada eje , como ejeX y ejeY, esta información sera desplegada cuando se genere un grafico en la aplicación. Los valores que se manejan en este rango , son descritos por dentro de <valoresRango>, cada valor tiene que tener un <valorRango>, en donde se introduce un numero, el cual indica , según el orden en que se generen el limite superior a obtener. En el fragmento anterior tenemos tres rangos, el primero va de 0-50, el segundo de 51 a 70 y el ultimo de 71 a 99. Cada uno de estos valores tiene un significado y un color el cual describe que color tomara cada rango, en el caso en que se genere una grafica. Para este ejemplo, tomaran los valores verde entre 0 y 50, amarillo entre 51 y 70, y por ultimo rojo entre 71-99. Los colores disponibles son BLACK, GRAY, WHITE, BLUE, CYAN, DARK_GRAY, GREEN, LIGHT_GRAY, MAGENTA, ORANGE, PINK, RED, YELLOW, estos son descritos en ingles con fines de estandarización. Para el manejo de exámenes absolutos, son definidos como un valor particular, los cuales tienen información que no se encuentra, en un rango de datos, ni en una enumeración especifica. A continuación un fragmento de la descripción final de exámenes, la cual se encuentra en el anexo 2. <campo nomcampo="Longitud"> <descripcioncampo/> <obligatorio>si</obligatorio> <tipocampo>real</tipocampo> <tipovalor> <absoluto limINF="0" limSUP="10" unidad="cms"/> </tipovalor> </campo> Este campo, a igual que en el de rango , tiene unos limites, los cuales describen y validan la información introducida por el usuario. En este caso es una información con un limite inferior “limINF”, igual a 0 y un 13.

(19) limite superior “limSup”, igual a 10. Tambien describen el tipo de unidad a introducir, en este caso la “unidad” será centímetros. Para tener noción de la diferencia entre los tipos de paneles rango, enumeración y absoluto, remitirse al capituló 6. El segundo descriptor denominado consultas, es el que especifica como se realizan la consulta en la base de datos, que información necesito pedirle al usuario para poderla efectuarlas y que información es la que deseo obtener para ser desplegada en la interfaz grafica. Un ejemplo de se describe en la siguiente pagina. <descriptores_consultas> <descriptor_consulta nombre_consulta="Consulta Prueba1"> <parametros_entrada> <parametro tipo_consulta="igual"> <etiqueta nombre_etiqueta="SEXO PACIENTE"/> <fuente_informacion nombre_examen="Paciente" campo_examen="Genero"/> </parametro> <parametro tipo_consulta="rango"> <etiqueta nombre_etiqueta="Fecha Nacimiento "/> <fuente_informacion nombre_examen="Paciente" campo_examen="Fecha nacimiento"/> </parametro> <parametro tipo_consulta="igual"> <etiqueta nombre_etiqueta="Diametro Carotida Comun"/> <fuente_informacion nombre_examen="Eco Modo B" campo_examen="Diametro vasos"/> </parametro> <parametro tipo_consulta="igual"> <etiqueta nombre_etiqueta="Placa Estudio Hemodinamico"/> <fuente_informacion nombre_examen="Estudio Hemodinamico" campo_examen="Modulo Poisson v"/> </parametro> </parametros_entrada> <parametros_salida tipo_resultado="grafica"> <parametro tipo_consulta=""> <etiqueta nombre_etiqueta="Placa Estudio Hemodinamico"/> <fuente_informacion nombre_examen="Estudio Hemodinamico" campo_examen="Modulo Poisson v"/> </parametro> <parametro tipo_consulta=""> <etiqueta nombre_etiqueta="SEXO PACIENTE"/> <fuente_informacion nombre_examen="Paciente" campo_examen="Genero"/> </parametro> </parametros_salida> </descriptor_consulta> </descriptores_consultas>. El descriptor de consultas puede contener una a muchas consultas a la vez, cada descriptor de consulta, tiene unos parámetros de entrada, que especifican a donde voy a acceder y que restricciones de información voy a colocar para realizar la consulta. Mientras que los parámetros de salida, generan información para seleccionar la información que deseo y como esta será mostrada al usuario final. La descripción y restricciones de los campos de una consulta se encuentran en el capitulo 4. En el anexo 2 se encuentra la descripción de la versión actual de este descriptor. Para obtener una noción grafica de cómo estos campos se ven en el software final, remitirse al capitulo 7. 14.

(20) 5.2. Definición del ambiente de desarrollo. 5.2.1. LENGUAJE. Para el entorno de desarrollo de la aplicación, la opción a seleccionar fue el lenguaje de programación Java, el cual es uno de los lenguajes mas utilizados actualmente por la industria por sus distintas características que se describirán a continuación: •. El JDK (Java Development Kit) es una herramienta libre, la cual provee una gran cantidad de posibilidades en el desarrollo. Esta se encuentra respaldada por una gran cantidad de proveedores. •. El desarrollo no solo esta acoplado a una plataforma. Este lenguaje es totalmente portable e independiente a la plataforma en que se este operando.. •. Existen plataformas graficas como Swing y SWT. Las cuales ofrecen la generación de interfaces gráficas altamente flexibles.. •. Permite el aprovechamiento total de la programación orientada a objetos.. •. El conocimiento, distribución y aplicación de la tecnología Java esta en alto crecimiento en la industrial mundial.. •. El acceso a una o varias bases de datos es simple debido al JDBC (Java Database Connectivity) que maneja.. •. El manejo de la bases de datos es transparente y simple. •. Para la manipulación de archivos XML, posee una diversidad de implementaciones como son XML, SAX, DOM y JDOM. 5.2.2. AMBIENTE DE PROGRAMACION. Para el ambiente de desarrollo se ha seleccionado la plataforma Eclipse. Esta plataforma tiene una muy buena característica, la cual es su licencia open-source (código abierto), este licenciamiento permite ser utilizada sin ningún costo. Entre las ventajas presentes en esta plataforma, además de su licencia, son las siguientes: •. Este IDE (Entorno Integrado de Desarrollo) fue patrocinada por una de las más grandes empresas de tecnología que existen actualmente, como es la IBM.. •. Es una plataforma totalmente portable (no esta sujeta a un sistema operativo).. •. Permite la utilización de la tecnología CVS (Concurrent Version System), lo cual será muy importante para el manejo de versiones durante la construcción del software.. •. Una excelente ventaja, es que este entorno se encuentra basado en plugins, lo que facilita esto altamente la integración con lenguajes y librerías. Hay que anotar que existen cientos de plugins de licencia GNU – GPL, ofreciendo esto, facilidades en el desarrollo de software.. 15.

(21) 5.3. Descripción de la arquitectura de la aplicación. La arquitectura concebida para poder lograr los objetivos impuestos de adaptabilidad e independencia entre la información y la aplicación, es una arquitectura que sea capaz de construir un mundo en base a unos descriptores XML.. Para poder realizar esta construcción de software, se utilizaron dos arquitecturas para el manejo de información, la primera de ellas es el patrón Singleton y la segunda es el patrón Builder, las cuales se describirán a continuación:. 1. Patrón Singleton: Este patrón fue implementado en la Fachada (capa del negocio). El garantiza una única instancia para el acceso a esta capa de datos. Debido a que el software es en un computador fijo (stand alone), no se tendrán problemas de peticiones simultaneas de una misma instancia y ayudaría esto al ahorro de memoria ya que no se creará una clase cada vez que se necesite, si no se mantendrá una disponible para las peticiones pertinentes. 2. Patrón Builder: Este patrón tiene como objetivo “Separar la construcción de un objeto complejo de su representación de modo que el mismo proceso de construcción pueda crear diferentes representaciones.”[22]. Por medio de este patrón, se puede construir el mundo de una forma dinámica en base a una clase directriz, la cual a medida en que se procesa el archivo descriptor, genera progresivamente la construcción del los objetos del mundo, garantizando esto, que al finalizar de la lectura del archivo, se disponga de unos objetos (mundo) que representen la información descrita en el XML. 5.3.1. Modelo del Mundo. 16.

(22) 5.3.2. Modelo y descripción del diseño. La arquitectura del sistema se planteo en tres capas, la primera es la capa de visualización, la segunda es la del negocio y la tercera de ellas es la de datos. Este modelo costa de una primera capa de visualización la cual es encargada por el paquete interfaz, la segunda capa que es la del negocio manejada por el paquete kernel.builder, kernel.Fachada, kernel.Handler, kernel.consultas, kernel.examenes y la tercera capa es la de datos manejada por el paquete kernel.bd.. 17.

(23) La primera capa es denominada como interfaz y se representa en el siguiente modelo. En la segunda capa, la capa del negocio, se manejan los objetos que realizarán la representación en memoria del descriptor definido en el XML (ver anexo 1); además de hacer la interacción entre la capa de visualización y la capa de datos.. 18.

(24) El siguiente modelo representa la capa del negocio y la interacción con las otras capas.. 19.

(25) El siguiente modelo UML, representa el paradigma representado por el descriptor de exámenes (ver anexo 1). 20.

(26) El siguiente modelo UML, representa el paradigma representado por el descriptor de consultas (ver anexo 1). Para poder representar de una forma eficiente la construcción del mundo en base a un descriptor XML, se planteo la utilización del patrón Builder. Este patrón trabajara conjuntamente con al tecnología de manipulación de documentos XML denominada SAXParser.. 21.

(27) A continuación se puede observar el modelo UML de este patrón implementado en la aplicación. Representación del Patrón Builder implementado en la aplicación. 22.

(28) LA Interacción entre los Handlers para el manejo de los descriptores de consultas y exámenes, con el patrón builder el cual creara los objetos e ira creando el mundo progresivamente como se vaya leyendo el archivo.. 23.

(29) 5.3.3. Arquitectura del software de interfaz. PanelBotones2. Panel Generico2. (from interfaz). (from interfaz). -botones -interfaz -interfaz InterfazAplicacion -interfaz -interfaz. layoutUtilities FactorDataConsul ti ng (from interfaz). (from interfaz). -consul tas. -datos FactorDataEntry (from interfaz). FactorPanel es (from interfaz). -graficos 1..* FactorChart. 1..*. FramePl aca. (from interfaz). PaletaCol ores (from interfaz). (from interfaz). FrameGrafi coExamen (from interfaz). 0..*0..*. FrameResultadosConsul ta (from interfaz). 0..*. FrameCalendari o. La arquitectura de la interfaz, tiene como fundamento la clase InterfazAplicacion, la cual es la encargada de generar e integrar tres módulos (descritos a continuación), además de la comunicación entre las diferentes capas de información que existen en esta herramienta. Esta clase, utiliza dos clases mas como complementos de visualización, una es denominada PanelGenerico2 y la otra PanelBotones2. La primera de ellas, es el encargado de organizar y distribuir de forma genérica cualquier panel, en donde este maneja dos botones para navegar sobre las pestañas de la interfaz grafica. Estos botones son descritos por la segunda clase, los cual es la encargada de recibir acciones y notificarlas a la interfaz para que estas sean actualizadas de forma automática en el software. Para la generación de graficas, paneles y consultas, la arquitectura de la interfaz se apoya entre módulos:. •. Generación de graficas: Este Modulo, esta compuesto por las clases FactorChart, PaletaColores. La primera clase es la encarga de generar todas las graficas que representan información como son barras, tortas, entre otras. La segunda clase es la encargada de generar los colores, si estos no son especificados en el descriptor de exámenes.. •. Generación de interfaces para introducir datos: Este Modulo, esta compuesto por la clase FactorDataEntry. Esta clase es la encargada de generar los paneles que serán integrados desplegados en la aplicación.. •. Generación de interfaces de consultas: Este Modulo, esta compuesto por las clases FactorDataConsulting y FrameResultadoConsulta. La primera, es la encargada de generar los paneles necesarios para desplegarle la información para las consultas. La segunda, es la encargada de mostrar la información en un pop-up.. 24.

(30) Cada uno de estos módulos utilizan las clases FactorPaneles, LayoutUtilities , FramePlaca (excepto para generación de consultas) y FrameCalendario. A continuación se describen: •. FactorPaneles: Tiene como objetivo la generación de Paneles, que son utilizados por la mayoría de los módulos en común, esto disminuye la cohesión entre los componentes de la interfaz.. •. LayoutUtilities: es la encargada del manejo de layout u ordenamiento tanto del un panel integrado por muchos paneles, como el ordenamiento y distribución interna de estos paneles pequeños.. •. FrameCalendario: Maneja el despliegue de un calendario para que el usuario pueda seleccionar una fecha especifica.. •. FramePlaca: Es el panel en donde se muestra la información de una placa en especifico.. 5.3.4. Diagrama de secuencias de inicio de la aplicación. : Interf azAplicac ion. : F ac hada. : DataBase. :XMLDirectorEx am enes. : ConcreteBuilder. : Fac torChart. : F actorD ataEntry. : FactorDataConsulting. 1: loadXML(Interf azAplicacion) 2: getXMLDescriptorConsultas ( ) 3: getXMLDescriptorConsultas ( ). 4:. 5: ConcreteBuilder(). 6: ( archiv o, elConstructor). 7: parse(archiv o,this). 8:. 9:. 10: F actorChart(Interf azAplicacion). 11: F actorDataEntry (Interf azAplic acion). 12: F actorDataC ons ulting(Interf azAplicacion). 13: s how( ). Para los f ines de este prototipo se em ula la interaccion c on la b.... 25.

(31) 6 ANALIS DE RESULTADOS. ¾. Características del producto desarrollado. Es un software que genera dinámicamente interfaces, basado en descriptores. Este software tiene la capacidad de independizar la información que interpreta, para construirse, de la información que representa en la interfaz, eso significa que la información es independiente al software. Esta aplicación se basa en descriptores XML (ver anexo 1 y 3), los cuales como su nombre lo indica, describen el tipo de información que se desea representar. El software se basa en esta información para generarse de forma dinámica, sin necesidad de modificación de código del sistema para una nueva visualización de la información. Esta generación automática permite al grupo de bioingeniería de la Universidad de los Andes la creación de exámenes, modificación de los antiguos o simplemente la eliminación de uno o vario de ellos sin necesidad de que estos cambios también deban ser realizados en el core del sistema. Las modificaciones realizadas por el grupo de expertos se harán sobre el descriptor XML (ver anexo1 y 3), y dinámicamente estos cambios se verán reflejados en la interfaz grafica de la aplicación. Esta herramienta tiene tres módulos para el manejo de la información: o. Modulo de entrada de información : Este modulo ofrece al usuario la posibilidad de introducir información en la base de datos, según lo estipulado por el descriptor XML (ver anexo 1). o. Módulo de visualización de información: Este módulo ofrece al usuario no solo una información alfa-numérica, si no da la posibilidad que esta información se convierta en modo gráfico para facilitar la interpretación de la misma. Este modulo se basa en el descriptor XML (ver anexo 1). o. Módulo de consultas de información: este módulo ofrece al usuario especificar consultas a la base de datos, en donde los resultados pueden ser gráficos o alfanuméricas sobre una información especifica descrita en un archivo XML (ver anexo 3). Esta herramienta por ser un prototipo, debe ser trabajada para obtener una aplicación con unos tiempos de respuesta óptimos, además de que puede adaptarse de una forma más general a cualquier tipo de descriptor estipulado, que siga unos parámetros más flexibles a los actuales. Esta prototipo independiente esta diseñada para ser acoplada con una base de datos y ser integrada en un posible sistema de información como SASE[2]. Sin embargo permite también ser reutilizado en otros desarrollos de software, en donde facilita la manipulación de información y evolución de la misma, sin necesidad de realizar mantenimiento al software.. A continuación se observa el funcionamiento de la aplicación desarrollada. 26.

(32) Al iniciar la aplicación, ésta se visualiza como se muestra en la figura 1:. Figura No.1 En la parte superior, se tiene una barra de botones, los cuales tienen unas funciones específicas, que se describen a continuación:. ¾. Entrada de Información. ¾. Visualización de información. ¾. Visualización de consultas. 27.

(33) 6.1. Introducción de Información:. Esta visualización proporciona al usuario la disposición de introducir información a una base de datos. En esta captura de pantalla se observa los distintos campos del examen “Paciente” descritos en el XML (ver anexo1), estos son separados de una manera que pueda ser visualizados e identificados fácilmente por el usuario, sin generar una densidad de información alfa-numérica.. Figura No.2 La separación de los exámenes se realiza por pestañas (siendo cada pestaña un examen) como se observa en la figura 2, de modo que el usuario puede introducir los datos de cualquier exámen, con solo presionar el nombre del examen, al que desea introducir información. Esto ofrece una mejor interacción con el usuario, ya que no se maneja una gran cantidad de datos de todos los exámenes si no, solo los estipulados por el descriptor del examen. En la Figura 3se visualiza el examen resultado de laboratorio, presionando la pestaña con ese nombre.. Figura No.3. 28.

(34) Examen “Resultados Laboratorio”. Figura No.4 Navegabilidad: La navegabilidad por medio de las pestañas se puede hacer de dos formas; la primera es presionando cada una de estas pestañas, las cuales representan un exámen especifico, la segunda opción es realizar el avance o retroceso de los exámenes mediante los botones que se encuentra en la parte inferior de la imagen anterior. Esto facilita a que la persona que se encuentre llenando muchos exámenes no tenga que ir siempre hasta la pestaña si no simplemente presione el botón ir a la siguiente pestaña (examen) o el botón. para. para ir a la anterior pestaña (exámen).. Para insertar la información de cualquier exámen es de una forma muy sencilla, ya que el usuario tiene botones para. o para. .. Cuando el usuario elige la opción de “Insertar Examen”, la información introducida se validará y si existen campos OBLIGATORIOS vacíos, como son descritos en el DTD (ver anexo 1). o la información. 29.

(35) introducida no es correcta, entonces se generará un mensaje de error en donde se le indica al usuario, cual fue el error y donde se produjo, para que éste lo corrija de una forma fácil y rápida. Si el usuario elige la opción de “Borrar Campos”, como su nombre lo dice, lo que hace es volver la pestaña a su estado inicial, borrando cualquier campo o selección realizada por el usuario. Cada exámen como fue definido en el DTD (ver Anexo) 1, tiene unos campos de exámen, en donde estos pueden o no tener un tipo de valor, haciendo esto que se diferencien en la interfaz, ya que los campos que no tienen tipo de valor, son observados como atributos del exámen, como son pueden ser una descripción, fechas o archivos asociados al exámen. Con el fin de separar estos dos tipos de información, lo que se hizo fue colocar una barra desplazable horizontalmente, la cual puede moverse para arriba o para abajo, con el fin de expandir o contraer cualquiera de los dos paneles ya sea el de atributos Figura No. 5 o el de campos del exámen Figura No.6, facilitando así la visualización de la información y además permitir que si un examen tiene muchos campos se puedan manejar sin ningún inconveniente, como se muestra a continuación:. Figura No.5. Figura No.6. En el Panel de atributos Figura 5 se pueden desplegar unos campos de fechas. Para el fin de una mejor interacción con usuario, se genera un pop-up para que éste, pueda seleccionar la fecha deseada y de esta manera no se necesite validación de la integridad de la fecha y se le de una facilidad grafica de selección al usuario. A continuación se puede observar esto en la figura No. 7: Este es el campo que vamos a manejar, como se puede observar aparece “No se ha seleccionado Fecha” 30.

(36) Figura No.7. A continuación presionamos el botón “Seleccionar Fecha” y aparecerá un calendario para el manejo de la fecha.. Figura No.8 Si el usuario selecciona la fecha Junio 21 del 2006, y presionamos el botón aceptar, aparecerá en el atributo fecha de ingreso la fecha seleccionada, como se observa:. Figura No.9 31.

(37) Para el manejo de archivos en los atributos del exámen, se pueden manipular de dos formas; la primera es seleccionar un archivo local del computador y la segunda es por medio de una dirección remota (URL). A continuación un ejemplo de esto:. Figura No.10 En este campo si presionamos “Seleccione archivo” se nos abrirá un pop-up para seleccionar el archivo deseado:. Figura No.11 Si el usuario presiona abrir este archivo denominado consultas.dtd, aparecerá la ubicación completo en el disco duro del usuario, del archivo seleccionado. Como se muestra a continuación:. Figura No.12 32.

(38) Si el usuario decide seleccionar URL archivo remoto, entonces el campo se modificara de esta manera. Figura No.13 En donde el usuario escribe una dirección URL, la cual se validará, si existe será insertada, de lo contrario se generará una ventana con el error pertinente. Para el manejo de los campos del exámen es de una forma muy fácil e intuitiva, ya que solamente existen dos tipos de visualización en donde en uno es seleccionar el resultado y en el otro, se introduce un resultado.. Figura No.14 En este tipo de campo se despliega al usuario, los rangos en que es válida la información, para así evitar que quien lo acceda pueda equivocarse en los mismos y de la misma manera verificar si la información del Descriptor del exámen se encuentra bien reseñada.. Figura No.15 En este otro tipo de campo, el usuario puede seleccionar solo un tipo de resultado, entre los que se despliegan. Esto evita una validación de la información introducida por el cliente, además facilita el manejo para el usuario final. Si se necesitan introducir placas, en un examen que lo permite según el descriptor, aparecerá un panel, en donde se presiona el botón “Insertar Placa” figura No. 16, el cual generara una pop-up con la información necesaria para la placa.. 33.

(39) Figura No.16. Figura No.17. Figura No. 18. Para insertar los datos de la placa en el pop-up se tendrán dos botones, por medio de los cuales se puede insertar la información o simplemente cancelar la inserción de la placa. Figura No.19. 34.

(40) 6.2. Visualización de Información:. En este modo de visualización, lo que se realiza son consultas a la base de datos, en base a un paciente específico, de tal modo que se pueda acceder a la información de los exámenes y datos relevantes del paciente. Para poder acceder a este modulo lo que se debe hacer es seleccionar el botón relacionado con este tipo de visualización, el cual es el segundo como se muestra en la imágen anterior.. En este tipo de visualización se sigue el mismo estándar anteriormente descrito, existe una separación clara entre los atributos del exámen y los campos del mismo; esta división se realiza por medio de una barra, la cual se puede mover para contraer o expandir la información de cada uno de los campos seleccionados.. Figura No.20. Figura No. 21. Para la visualización de los resultados, pueden aparecer dos tipos de interfaces: 1. La primera es información alfa-numérica, en donde se muestra claramente el resultado del examen y además se da información adicional sobre los rangos límites en que puede estar el examen, para así, hacer una mejor apreciación y entendimiento del mismo.. Figura No.22. 35.

(41) 2. La segunda forma de visualización, es un resultado numérico, con el cual se puede obtener una grafica, generando esto, una gran aporte porque muestra gráficamente al usuario la información y como esta relacionada según el valor en que se encuentra el resultado del examen. Como se muestra en el siguiente panel el resultado de la viscosidad de la sangre es 1.0. Si el usuario desea ver la interpretación grafica del mismo, puede oprimir el botón “Ver Resultado”, el cual generara un pop-up con la información grafica y la relación con otros resultadazos de viscosidad en la sangre.. Figura No.23. Resultado. del. Descripción de los resultados según el color que aparece en la. Ampliación de la descripción de los resultados Figura No.24 Estos estilos de graficas se generan según la descripción del examen (ver anexo 2), Si el examen es de tipo enumeración como fue la anterior imagen de “Viscosidad sangre,” se genera una grafica de tipo Pie. En esta grafica se describe cada uno de los posibles resultados del examen, así mismo sobresale el resultado del paciente, separando del grafico en general el resultado obtenido, para nuestro ejemplo seria el resultado Newtoniano. Si el examen es de tipo Rango, entonces se mostrara una barra en la cual se describieran todos los rangos posibles del examen, y cada rango tendrá su propia descripción y color. El resultado del examen del paciente será resaltado en relieve como se observa en la figura No. 26:. 36.

(42) Figura No.25. Rango en el que se encuentra el Paciente. Resultado del Examen. Descripción de los resultados según el color que aparece en la grafica Figura No.26. 37.

(43) 6.3. Consulta de Información:. Este modulo de consulta de información, tiene como objetivo hacer consultas en la base de datos según unos parámetros especificados en el descriptor de consultas (ver anexo 4). Estos parámetros describen los valores de entrada que se necesitan para realizar la consulta y unos valores de salida esperados. Los valores de entrada siempre será información alfa-numérica, mientras que los valores de salida puede ser información grafica o alfa-numérica. Hasta el momento solo se encuentran descritas tres consultas (ver anexo 4), es por ello que al acceder a este modulo solo de despliega lo siguiente descrito en la figura 27:. Consultas descritas. Panel en el que se generara la consulta. Botón para generar la consulta. Figura No.27. Para poder apreciar de una manera mas aplicable este modulo, se realizara las consultas para apreciar los tipos de resultado que se generan en ellas. A continuación se describen cada una de las tres consultas y sus resultados. 1. La consulta 1 desea obtener una grafica de tiempo en donde se le haga el seguimiento a un paciente en particular según una fecha de cita inicial y final, un sexo, diámetro vasos carótida común y el modulo Poisson v. Ver Figura 28. 38.

(44) Al generar esta consulta aparecer esto en la interfaz:. Figura No.28 En el panel derecho, aparecen campos vacíos para introducir los datos necesarios para realizar la consulta, si estos datos no son introducidos correctamente y se presiona el botón generara una ventana de error, indicándole al usuario porque no se puede realizar la consulta.. , se. Es error se mostrar de la siguiente forma:. Figura No.29. 39.

(45) Si la consulta no tiene ningún error, se realizara la consulta y se generara un resultado como el siguiente:. Figura No.30 En esta consulta se genera una serie de tiempo, donde se muestran los resultados de peso de un paciente vs. la fecha en que fue tomado y así, observar las variaciones que se han llevado en un lapso de tiempo especifico.. Tipo de Examen o muestra. Fechas en que fueron obtenidas las muestras o exámenes. Figura No.31. 40.

(46) 2. La consulta 2 desea obtener unos valores alfanuméricos como resultado. Para ello se selecciona la consulta y se procede a presionar el botón generar consulta y asi generar el panel derecho con los campos necesarios para efectuar la consulta.. Figura No.32 Como se puede observar en la figura 32, para no tener que validar información se le despliega al usuario unos campos en los cuales el solamente tiene que elegir los resultados, ya sean fechas, o algunos campos, excepto un campo de texto por ejemplo para introducir la cedula del paciente o algún otro tipo de valor, según lo que se solicite en el descriptor de consultas. Campo para seleccionar un resultado. Figura No.33. Campo para introducir un valor alfa-numérico. Figura No.34. 41.

(47) Después de introducir los valores validos necesarios para la consulta, el resultado es un panel con los resultados alfa-numéricos descritos en la consulta (Ver anexo 4). Figura No.35 Este seria el pop-up de los resultados alfa-numéricos. Figura No.36. 42.

(48) 3. La consulta 3, al igual que la consulta 1 tiene descrito como resultado de salida una grafica. Debido a que no tiene un rango de fechas, se genera una grafica de dispersión con los valores obtenidos en la base datos. El procedimiento para realizar la consulta es exactamente igual al anterior descrito.. Figura No.37 Después de introducir los valores necesarios para la consulta referenciados en el descriptor de consultas (Ver anexo 4), se genera un pop-up con la grafica de dispersión como se muestra en la figura No. 38.. Figura No.38 Debido a la gran cantidad de datos descritos en esta consulta, la grafica tiene la opción de realizar un Zoom sobre los resultados como se muestra a continuación 43.

(49) Figura No.39. Figura No.40. Para realizar este zoom, se debe mantener presionado el botón izquierdo del Mouse y arrastrarlo hasta donde se desea el enfoque en la grafica, mientras se hace esto se genera una sombra sobre la selección. Al realizar el zoom, se modifican los valores de los ejes y se muestran de esta manera un nuevo enfoque sobre la grafica. Para volver al estado original de la grafica, simplemente se presiona el botón izquierdo sobre la grafica y se mueve el Mouse hacia la izquierda volviendo al estado inicial de la grafica.. Figura No.42. 44.

(50) 7. CONCLUSIONES. El principal logro fue el completo desarrollo de una aplicación, la cual tiene como principal característica la independencia y separación entre el software y la información representada en el mismo. Estas características generan flexibilidad del software ante nuevas demandas o tendencias de información. El tipo de arquitectura desarrollada es un paso para reevaluar el paradigma existente en el modelamiento desarrollo de software, y la relación constante que existe entre la información que se contiene y la información que se despliega. Al permitir esta separación, se obtienen beneficios en el mantenimiento de la aplicación, ya que esta al adaptarse a las nuevas tendencias de información, no se necesita de modificaciones al código fuente; basta con distribuir nuevamente la información en los descriptores (ver anexos 2 y 4) y la herramienta se genera y despliega de forma flexible, y en ocasiones dinámica, como el caso del módulo de consultas. Por ser desarrollado como un modulo independiente, es integrable a una nueva aplicación, permitiendo la reutilización del mismo en otros objetivos de desarrollo.. 45.

(51) 8 BIBLIOGRAFIA 1. Uriza L.F., Arias J.A., Nieto E.M., Hernández Hoyos M., Briceño J.C. "Desarrollo de un modelo computacional para estudio de la enfermedad arteriosclerótica carotídea". XXIX Congreso Nacional de Radiología, Octubre 2004, Cartagena, Colombia. 2. Proyecto de investigación SASE[2] – “Análisis interactivo y almacenamiento distribuido de imágenes médicas 3D” - Proyecto europeo código C03S02 – 2004 3. Sun Microsystem Inc.: Java http://java.sun.com/products/jfc/. Marzo 2006. Foundation. Classes. Overview. (JFC). 4. Steve Northover, OTI : SWT: The Standard Widget Toolkit Marzo 22 del 2001 , http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html 5. Josh Fletcher : AWT vs Swing, http://bdn2.borland.com/article/26970, accedido el 30 de Marzo del 2006 6. Barry Feigenbaum: SWT, Swing or AWT: Which is right for you?, http://www128.ibm.com/developerworks/library/os-swingswt/index.html, accedido el 30 de Marzo del 2006 7. Anónimo: Swing vs AWT vs SWT vs .http://www.leepoint.net/JavaBasics/gui-commentary/guicom25-swingawtswtxul.html, accedido el 30 de Marzo del 2006. 8. Pablo Castells: Interfaces graficas de usuario, http://www.ii.uam.es/~castells/docencia/poo/11swing.pdf, accedido el 5 de Abril del 2006 9. Iván García Puebla: SWT: el nuevo sistema de desarrollo de GUIs en Java, http://www.gui.uva.es/~laertes/nuke/index.php?option=com_content&task=view&id=54&Itemid=41 , accedido el 5 de Abril del 10. Mauro Marinilli :Swing and SWT: A Tale of Two Java GUI http://www.developer.com/java/other/article.php/2179061, accedido el 5 de Abril del. Libraries,. 11. Andreas Viklund: JFreeChart http://www.jfree.org/jfreechart/, accedido el 5 de Abril del 2006 12. Visual Mining: Visual Mining, http://www.visualmining.com/, accedido el 5 de Abril del 2006 13. Big Faceless Organization: Big Faceless Graph Library, http://big.faceless.org/products/graph/, accedido el 5 de Abril del 2006 14. Department of EECS, UC Berkeley : Ptplot, http://ptolemy.eecs.berkeley.edu/java/ptplot/, accedido el 5 de Abril del 2006 15. Visual Enginnering: KaVaChart , http://www.ve.com/, accedido el 5 de Abril del 2006 16. Jason J. Simas: Chart2D, http://chart2d.sourceforge.net/, accedido el 5 de Abril del 2006 17. The Krysalis Community Project: JChart, http://jcharts.sourceforge.net/, accedido el 5 de Abril del 2006. 46.

(52) 18. Sebastian Müller: JOpenChart Library and Toolkit, http://jopenchart.sourceforge.net/, accedido el 5 de Abril del 2006 19. David BRAHIM :XmlCharts , http://xmlchart.sourceforge.net/, accedido el 5 de Abril del 2006 20. The Apache Software Foundation: Xerces Java Parser Readme http://xerces.apache.org/xercesj/, accedido el 16 de Abril del 2006 21. Anonimo : NachoCalendar, http://nachocalendar.sourceforge.net/, accedido el 22 de Abril del 2006 22. Marta L. Anaya, Vladimir Bronnikov.” Patron de Diseño: Builder” , http://agamenon.uniAndes.edu.co/~pfiguero/soo/PatronesDiseno/Builder/Builder.html, accedido el 6 de abril del 2006.. 47.

(53) 9 9.1. ANEXOS. Anexo 1 : Definición descriptor exámenes. <?xml version="1.0" encoding="ISO-8859-1"?> <!ELEMENT EXAMENES (Examen*)>  <!ELEMENT Examen (campo+,placa?)>  <!ATTLIST Examen nombre CDATA #REQUIRED > <!ELEMENT placa (campo+)> <!ELEMENT campo (descripcioncampo, obligatorio, tipocampo, tipovalor?)> <!ATTLIST campo nomcampo CDATA #REQUIRED >   <!ELEMENT descripcioncampo (#PCDATA)> <!ELEMENT obligatorio (#PCDATA)> <!ELEMENT tipocampo (#PCDATA)>  <!ELEMENT tipovalor (enumeracion | rango | absoluto | curva)>  <!ELEMENT rango (valoresRango+)> <!ATTLIST rango limINF CDATA #REQUIRED limSUP CDATA #REQUIRED ejeX CDATA #REQUIRED ejeY CDATA #REQUIRED > <!ELEMENT valoresRango (valorRango, significadoRango,colorRango)> <!ELEMENT valorRango (#PCDATA)> <!ELEMENT significadoRango (#PCDATA)> <!ELEMENT colorRango (#PCDATA)> <!ELEMENT valores (valor, significado)> <!ELEMENT valor (#PCDATA)> <!ELEMENT significado (#PCDATA)>  <!ELEMENT enumeracion (valores+)>  <!ELEMENT absoluto (#PCDATA)> <!ATTLIST absoluto limINF CDATA #REQUIRED limSUP CDATA #REQUIRED significado CDATA #REQUIRED >  <!ELEMENT curva (valoresXY+)> <!ATTLIST curva minX CDATA #REQUIRED minY CDATA #REQUIRED maxX CDATA #REQUIRED maxY CDATA #REQUIRED nomX CDATA #REQUIRED nomY CDATA #REQUIRED unidX CDATA #REQUIRED unidY CDATA #REQUIRED > <!ELEMENT valoresXY (valorX, valorY)> <!ELEMENT valorX (#PCDATA)> <!ELEMENT valorY (#PCDATA)>. 48.