u281938

Vista previa del material en texto

Generación de interfaces gráficas
basadas en descriptores XML
Juan Erasmo Gómez Morantes
Universidad de los Andes
Facultad de Ingenieŕıa
Departamento de Ingenieŕıa de Sistemas y Computación
Bogotá, D.C.
1 de febrero de 2007
Generación de interfaces gráficas
basadas en descriptores XML
Juan Erasmo Gómez Morantes
Trabajo de Grado para optar al titulo de Ingeniero de Sistemas y
Computación
Asesora:
Dra CLAUDIA LUCIA JIMENEZ GUARIN
Universidad de los Andes
Facultad de Ingenieŕıa
Departamento de Ingenieŕıa de Sistemas y Computación
Bogotá, D.C.
1 de febrero de 2007
A mi padre y a mi madre.
1
AGRADECIMIENTOS
Agradezco profundamente a:
Claudia Jimenez, asesora de este trabajo, por su orientación, paciencia y confi-
anza a lo largo de este proyecto.
Marcela Hernandez, directora del proyecto de investigación, por brindarnos la
oportunidad de participar en el.
Sergio Daniel Moreno, Camilo Jimenez y Julian Grijalba por su colaboración,
trabajo e ideas dentro del proyecto.
Los personajes del Z-115 por ayudarme en este proceso y por el buen ambi-
ente de trabajo que crearon.
A Luis Felipe Uriza y Angela Iragorri por su invaluable colaboración y aporte
no solo a este trabajo, sino a todo el proyecto.
2
Índice
1. Introducción 6
2. Objetivos 7
2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Objetivos espećıficos . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Antecedentes del proyecto 8
3.1. Modelo general de datos . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Descriptores de información y relaciones . . . . . . . . . . . . . . 10
3.3. Arquitectura general del sistema . . . . . . . . . . . . . . . . . . 10
4. Diseño de la solución 12
4.1. Requerimientos del sistema . . . . . . . . . . . . . . . . . . . . . 12
4.2. Decisiones de diseño . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Decisiones de interacción . . . . . . . . . . . . . . . . . . 14
4.2.2. Correspondencia visual entre entidades y elementos gráficos 14
4.2.3. Generación automática de la interfaz . . . . . . . . . . . . 15
4.3. Modelo de arquitectura de la capa de interfaz . . . . . . . . . . . 16
4.4. Modelo de clases de la capa de interfaz . . . . . . . . . . . . . . . 17
5. Módulo de consultas 19
5.1. Consideraciones de diseño . . . . . . . . . . . . . . . . . . . . . . 19
5.1.1. Consideraciones de funcionalidad . . . . . . . . . . . . . . 19
5.1.2. El formato de definición . . . . . . . . . . . . . . . . . . . 20
5.2. Tipo de consultas soportadas . . . . . . . . . . . . . . . . . . . . 20
5.2.1. Formato de consultas . . . . . . . . . . . . . . . . . . . . 20
5.2.2. Datos multivalor . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.3. Formas de despliegue de los resultados . . . . . . . . . . . 22
5.3. Diseño del módulo . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Implementación de la solución 25
6.1. Base tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Implementación de componentes visuales . . . . . . . . . . . . . . 25
6.2.1. Representación gráfica de un examen . . . . . . . . . . . . 26
6.2.2. Representación gráfica de los campos . . . . . . . . . . . . 26
6.2.3. Los diferentes tipos de campos . . . . . . . . . . . . . . . 27
7. Análisis de resultados 31
8. Conclusiones y trabajo futuro 32
Apendices 35
A. Ejemplo de archivo de definición de información 35
3
B. Ejemplo de archivo de relaciones 38
4
Índice de figuras
1. Modelo de datos general manejado por los expertos . . . . . . . . 9
2. Arquitectura general del sistema . . . . . . . . . . . . . . . . . . 10
3. Menú de acciones del sistema . . . . . . . . . . . . . . . . . . . . 14
4. Ejemplos de diálogos de interacción . . . . . . . . . . . . . . . . . 15
5. Arquitectura general de la capa de interfaz . . . . . . . . . . . . 16
6. Modelo de clases de la capa de interfaz . . . . . . . . . . . . . . . 17
7. Modelo de datos multivalor . . . . . . . . . . . . . . . . . . . . . 22
8. Formas de despliegue de los resultados de una consulta . . . . . . 23
9. Diagrama de clases referente al módulo de consultas . . . . . . . 23
10. Representación gráfica de un examen . . . . . . . . . . . . . . . . 26
11. Representación gráfica de un campo . . . . . . . . . . . . . . . . 27
12. Ingreso de una fecha . . . . . . . . . . . . . . . . . . . . . . . . . 27
13. Ingreso de un dato enumerable . . . . . . . . . . . . . . . . . . . 28
14. Ingreso de un campo tipo rango . . . . . . . . . . . . . . . . . . . 28
15. Despliegue de un campo tipo rango . . . . . . . . . . . . . . . . . 29
16. Gráfica representativa de un rango . . . . . . . . . . . . . . . . . 29
17. Forma de ingreso y despliegue de un dato de valor absoluto . . . 30
18. Ingreso de un campo de archivo . . . . . . . . . . . . . . . . . . . 30
5
1. Introducción
Al trabajar en proyectos de investigación interdiciplinarios, uno de los prin-
cipales retos es tener una comunicación efectiva entre las diferentes disciplinas
que se ven involucradas en este proceso. Esto incluye el uso de lenguaje y formas
de expresión propias de cada disciplina. Otro de los retos es manejar de manera
adecuada la evolución propia de proyectos investigativos que tienen que adaptar
sus procesos a los resultados parciales que la investigación vaya arrojando.
Dentro del grupo de investigación de bioingenieria de la Universidad de
los Andes se desarrolla el proyecto de investigación llamado “Estudio de la
hemodinámica a través de una estenosis de la bifurcación de la arteria carótida
y su influencia en las observaciones cĺınicas. Parte II: Integración del análisis
de imágenes médicas y hemodinámico para la toma de decisiones en pacientes
con enfermedad arterioesclerótica carotidea” en el que estos dos retos son de
suma importancia y se podŕıa decir que de su adecuado manejo dependen la
calidad de resultados que arroje la investigación. Este proyecto esta enmarcado
dentro de los proyectos Colciencias código 12040416468 y CIFI 65 [UAN+04]
[Pro] [ANU+05].
El objetivo de este trabajo es, construir un sistema de información en el cual
la especificación de requerimientos funcionales y no funcionales gira en torno
a la inserción y el despliegue de información simple. El problema es que dicha
información no es estable y muchas veces no se conoce.
Para solucionar esto se propuso una herramienta que desacopla totalmente
los requerimientos funcionales de la información que se quiere manejar con la
aplicación. Este trabajo fue empezado por Julian Eduardo Grijalba [Gri06] y
complementado por los miembros del grupo de investigación en el contexto de los
proyectos citados[JGJ+06]. Lo que se pretende con esta aplicación es permitir a
los expertos definir la información que les es necesario manejar y de esta forma
agilizar el proceso evolutivo del software. Adicional a esto, la aplicación permite
la definición de consultas complejas que se ejecutan sobre los datos almacenados
en esta y que también pueden ser modificadas por los expertos sin que esto tenga
mayores implicaciones sobre el software desarrollado.
El proceso de generación y evolución de la aplicación gira en torno a un
archivo de definición de datos en el que los expertos definen las entidades que
para ellos sean relevantes, un archivo de relaciones en el que los expertos definen
las relaciones entre las entidades previamente definidas y varios archivos de
consultas en el que los expertos definen las consultas que consideren relevantes
dentro del contexto de la investigación.
6
2. Objetivos
2.1. Objetivo General
Construir un ambiente gráfico que permita la inserción y el despliegue de
datos y la navegación a través de los mismos desacoplando totalmente estos
requerimientos de la definición de la información manejada por el sistema.
2.2. Objetivos espećıficos
Desarrollar una interfaz gráfica de acuerdo con los descriptores de infor-
mación y de relaciones que definenal sistema.
Hacer uso de las mejores practicas de reutilización y patrones de diseño
para la generación dinámica de la interfaz.
Diseñar gráficamente la interfaz para que sea intuitiva, amigable y fácil de
manejar.
7
3. Antecedentes del proyecto
En su primera versión la aplicación se desarrolló en dos frentes. Por un
lado se desarrolló la capa de interfaz [Gri06] y por otro lado se desarrollaron las
capas de control y persistencia. Esto resultó en dos componentes que aun cuando
cumpĺıan con los requerimientos definidos para la versión estaban aislados. Aśı,
la primera labor fue tratar de integrar estas dos partes; El componente que
incluye las capas de control y persistencia fue desarrollado por Camilo Jimenez
y Sergio Moreno.
Durante este proceso se encontraron algunos problemas que hicieron muy
dif́ıcil la integración. Se vio que los componentes no eran compatibles, ya que
usaban protocolos diferentes para tratar de comunicarse el uno con el otro.
Los supuestos que se teńıan a la hora de desarrollar la primera versión dejaron
de ser ciertos, y se hicieron modificaciones sobre el modelo de datos que no
eran soportadas por el sistema. También se encontraron decisiones de diseño de
la interfaz muy acopladas que haćıan dif́ıcil modificar el sistema para que se
ajustara a los nuevos supuestos y al nuevo modelo de datos.
Estos problemas llevaron al rediseño del sistema, reutilizando los compo-
nentes que nos eran útiles, pero proponiendo una nueva arquitectura que se
ajustara a las necesidades manifestadas por los expertos. Esto incluye modifi-
caciones en la representación gráfica de las entidades, cambios profundos en la
navegabilidad de la interfaz y un nuevo modelo de datos (se modifico la forma
de definir las entidades).
El componente de consultas, que se encontraba implementado parcialmente,
fue descartado debido a lo dif́ıcil que resultaba definir una consulta en el for-
mato que se adopto en ese momento. Este formato fue reemplazado por uno
más simple que bajaba la dificultad y el tiempo requerido para la definición de
consultas por parte de los expertos.
3.1. Modelo general de datos
En la figura 1 se muestra el modelo de datos general utilizado por los expertos
para el proyecto Colciencias que enmarca este trabajo.
En este modelo se ve que un paciente puede tener muchas series de imágenes
diagnosticas, y cada una de estas series puede tener una instancia de cada exa-
men (IACID, AngioResonancia, ASD, ...). Cada uno de estos exámenes puede
tener asociado el diagnóstico de muchas placas, lo cual corresponde a indi-
cios de estenosis en la arteria carótida. Es importante resaltar que las placas
se definen independientemente dando como resultado unidades de información
8
Figura 1: Modelo de datos general manejado por los expertos
heterogéneas aśı se estén refiriendo al mismo concepto.
En este contexto, un examen corresponde a los resultados de un método
diagnóstico dentro de los varios métodos considerados para el proyecto.
Un paciente también puede tener otros exámenes como Análisis cĺınico, Re-
sultados de laboratorio, Reporte estructural, etc. Estos exámenes, que no de-
penden de una serie, no tiene asociado el diagnóstico de placas.
Todos los exámenes están compuestos por campos que pueden ser del tipo
texto, fecha, numero entero, numero real o booleano. Existen campos que pueden
ser complejos como enumeraciones, rangos y valores absolutos.
Cabe anotar que este modelo es muy inestable, ya que depende del avance
del proyecto de investigación, y tiene que ajustarse a las necesidades que van
surgiendo en el desarrollo del proyecto y de ah́ı la importancia de desacoplar
esta información de los requerimientos funcionales y no funcionales del sistema.
9
3.2. Descriptores de información y relaciones
Los descriptores se escribieron usando un formato XML definido por el grupo
de investigación.
Este formato tiene como primer objetivo la facilidad de escritura e inter-
pretación, permitiendo aśı que los expertos (no necesariamente ingenieros) puedan
entender y modificar estos descriptores para ajustarlos a sus necesidades.
Dentro del contexto del proyecto, un examen es considerado como una
entidad que es, a su ves, un conjunto de campos. El archivo descriptor de
información puede ser visto como un conjunto de exámenes.
El descriptor de información contiene la definición de las entidades a manejar
(series, exámenes, campos y placas) en cuanto a su definición, las restricciones
semánticas, de integridad y su forma de visualización. Un ejemplo de este de-
scriptor se encuentra en el apéndice A.
El descriptor de relaciones también está escrito en un formato XML. Su
función es definir las dependencias que existen entre las diferentes entidades y
la forma de identificar los exámenes. Un examen puede tener un identificador
generado o se puede usar uno de los campos que lo componen como identificador.
Un ejemplo de este descriptor se encuentra en el apéndice B.
3.3. Arquitectura general del sistema
Figura 2: Arquitectura general del sistema
10
El sistema esta construido usando una arquitectura multinivel; Dentro de
esta arquitectura se definen 3 capas que son:
Interfaz
Control
Persistencia
Capa de interfaz La capa de interfaz es la encargada de manejar la in-
teracción con el usuario; Se puede ubicar en la figura 2 como el componente
GUIDynamicClient.
Capa de control Esta capa es la encargada de ofrecer los servicios que
cumplen con los requerimientos funcionales y no funcionales de la aplicación,
también esta encargada de mediar entre las capas de interfaz y persistencia; Se
puede ubicar en la figura 2 como el componente carotidaFacadeBean.
Capa de persistencia La capa de persistencia es la encargada del manejo de
la base de datos del sistema; Se puede ubicar en la figura 2 como el componente
carotidaHibernate.
En la figura 2 se puede observar un componente llamado carotidaGenerator
el cual es el encargado de la generación de las capas de control y persistencia a
partir de los archivos descriptores del sistema.
Si bien el sistema de información descrito en esta arquitectura es generado
con este software, este trabajo se centra en la capa de interfaz.
11
4. Diseño de la solución
El principal problema que se soluciona con esta aplicación es el costo de
mantener un sistema en el que la definición de la información manejada cambia
constantemente.
Este problema se manifestó dentro del proyecto de investigación que enmarca
este trabajo de muchas formas:
Es necesario introducir nuevos exámenes, que le den a los expertos ele-
mentos de juicio para seguir con la investigación.
La cantidad de campos que describen a algunos exámenes hace necesario
que estos sean divididos en múltiples exámenes.
Es necesario agregar nuevos campos a un examen, modificar los campos
existentes o eliminar algunos capos a medida que los expertos lo consideren
necesario.
La definición de los campos es muy volátil en cuanto a restricciones semánti-
cas, nombre o tipo de dato a manejar.
La solución propuesta consiste en definir la información a manejar y sus
relaciones en archivos XML y a partir de estos archivos, generar una aplicación
que cumpla con los requerimientos que los expertos han manifestado.
En este capitulo no se tratara el tema del modulo de consultas ya que este
esta cubierto en la sección 5
4.1. Requerimientos del sistema
Los requerimientos funcionales de la aplicación se basan en 3 operaciones
básicas:
Inserción de información: El sistema permite la inserción de información
tomando en cuenta la definición que de esta han hecho los expertos.
El ingreso de información de un examen se hace de manera independiente
al ingreso de otros y el sistema mantiene todas las restricciones de integridad
definidas en los archivos de definición de información y relaciones.
12
Despliegue de información: El sistema de información permite el despliegue
de la información ingresada porlos usuarios. Esto lo hace desplegando los
exámenes de forma completa y de ser necesario, las placas asociadas con es-
tos. Este requerimiento no debe confundirse con el requerimiento de realización
de consultas, el cual sera expuesto a continuación.
Definición y realización de consultas: El sistema permite que los exper-
tos definan las consultas que ellos consideren necesarias para el desarrollo de la
investigación usando la información consignada en los archivos de definición de
información y relaciones; el sistema está en capacidad de procesar estas consul-
tas y desplegar los resultados de las mismas sin que se tenga que modificar la
aplicación.
Persistencia de consultas: Las consultas definidas por los expertos son per-
sistentes en forma de archivos de texto que pueden ser cargados a la aplicación
al momento de realizar la consulta.
Los requerimientos no funcionales son los que se esperan en cualquier sistema
de información de alto nivel y son expuestos a continuación.
Distribución: El sistema permite que múltiples usuarios hagan uso de este al
mismo tiempo, esto permite el reparto de tareas dentro del grupo de expertos.
Interfaz gráfica: El sistema interactúa con el usuario a través de una in-
terfaz gráfica poniendo a disposición del usuario todos los elementos gráficos
necesario para representar las entidades consignadas en el archivo de definición
de información.
Persistencia de Base de Datos: El sistema usa un sistema manejador de
bases de datos (SMBD) relacional encargado de la persistencia de la base de
datos de la aplicación1.
Transaccionalidad: El sistema opera de manera transaccional garantizando
aśı la integridad de las operaciones que se realicen sobre la base de datos de la
aplicación.
1En este punto el autor considera importante resaltar la diferencia entre base de datos
y sistema manejador de bases de datos. Una base de datos es un conjunto de información,
mientras que un sistema manejador de bases de datos es la tecnoloǵıa que se encarga de
manejar este información
13
Es importante resaltar que ninguno de los requerimientos expuestos en esta
sección están atados al modelo de datos del sistema (ver figura 1 en la pagina
9). Esto hace que el modelo pueda ser cambiado sin afectar el cumplimiento de
los requerimientos.
4.2. Decisiones de diseño
Dentro del estudio del problema y la solución se tomaron decisiones de
diseño. Conocer estas decisiones es vital para entender el sistemas ya que sobre
ellas se basa el desarrollo de la aplicación.
4.2.1. Decisiones de interacción
La interacción del sistema se diseño alrededor del menú de acciones dentro
de la interfaz gráfica y el uso de diálogos.
Figura 3: Menú de acciones del sistema
Cada una de estas acciones lleva al usuario a una pantalla en la que puede
llevar a cabo la operación deseada. Ejemplos de estas pantallas pueden encon-
trarse en al sección 6.2.
Cuando se trata con entidades multivalor (relaciones uno-a-muchos o muchos-
muchos) la navegación se hace de manera secuencias usando diálogos.
4.2.2. Correspondencia visual entre entidades y elementos gráficos
Cada entidad tiene un elemento gráfico que lo representa gráficamente. Esto
se cumple tanto para exámenes como para campos y placas; lo cual implica
14
Figura 4: Ejemplos de diálogos de interacción
que si una entidad es un conjunto de otras (por ejemplo, un examen es un
conjunto de campos) su elemento gráfico correspondiente sera una composición
de elementos que representan otras entidades.
Hay ciertas entidades que permiten interacción con el usuario, por ejemplo,
un campo de rango permite ver una gráfica que ubica el valor seleccionado
dentro de los rango validos especificados para el campo.
4.2.3. Generación automática de la interfaz
Para efectos de generación de la interfaz se decidió diseñar elementos genéri-
cos que pudieran representar cualquier entidad definida dentro del archivo de
definición de información.
Para este fin se construyen abstracciones que representan las entidades en
términos de su descripción y abstracciones que representan sus elementos gráfi-
cos correspondientes. En el caso de los elementos gráficos se incluye una es-
tructura de herencia profunda que ofrece facilidades de mantenimiento y cortos
tiempos de desarrollo.
Para la instanciación de los elementos gráficos se implementa un patrón
factory[GHJV95] que desacopla el proceso de relacionar entidades y elementos
gráficos.
15
Figura 5: Arquitectura general de la capa de interfaz
4.3. Modelo de arquitectura de la capa de interfaz
La figura 5 muestra la arquitectura general de la capa de interfaz.
El paquete interface es el encargado del diseño de la visualización. En el
se encuentran definidos todos los paneles que representan los diferentes tipos de
campos, los elementos gráficos referentes a los exámenes y a las placas y todo el
manejo de interacción con el usuario. Para definir la forma de visualizar los cam-
pos, placas y exámenes este paquete se comunica con el paquete descriptors
ya que este es el responsable de mantener esta información.
El paquete descriptors es el encargado de mantener el modelo de un exa-
men, un campo o una placa como unidad de información y de manera general
(no confundir esto con representación directa del modelo presentado en la sec-
ción 3.1). Esta información es producto del procesamiento del descriptor de
información, lo cual es tarea del paquete parser.
El paquete parser procesa el archivo XML descriptor de información para
producir la estructura de datos que representa la información plasmada en este
archivo.
16
Toda la comunicación con la capa de control esta concentrada en el paquete
facade. Este es el encargado de hacer las peticiones a la capa de control después
de recibir la orden desde el paquete interface.
El paquete exceptions contiene las excepciones usadas para manejo de error
dentro de la aplicación y el paquete util contiene clases utilitarias que soportan
procesos principalmente de manejo de archivos de configuración.
4.4. Modelo de clases de la capa de interfaz
Figura 6: Modelo de clases de la capa de interfaz
La figura 6 muestra el modelo de clases de la capa de interfaz.
17
Dentro de este se pueden ver todos los elementos gráficos usados para la
visualización de la información. Estos elementos se encuentran en el paquete
interfaz.
A continuación se describen las clases principales y sus responsabilidades.
PanelCampo y PanelFactory Estas clases son las principales responsables
del manejo gráfico de los campos.
PanelCampo representa la abstracción de la cual heredan todas las representación
de campo necesarias para visualizar las unidades de información propuestas.
PanelFactory es la clase encargada de instanciar los paneles en forma correcta.
PanelDespliegueExamen y PanelIngresoExamen Estas clases son las en-
cargadas de organizar los campos (representados por instancias de la clase
PanelCampo) pertenecientes a un examen dentro de un panel que es la rep-
resentación gráfica del examen.
InterfazAplicacion Esta clase es la clase ejecutable.
En ella se encierra gran parte del manejo de interacción con el usuario.
Los descriptores Todas las clases en el paquete descriptores son impor-
tantes. Estas modelan las entidades(examen, campos y placa) como unidades de
información. Su importancia radica en que esta estructura de datos es la base
para la generación de la interfaz gráfica.
Parser La clase parser es la encargada de dirigir el procesamiento del archi-
vo de definición de información y generar, apoyándose en el paquete descriptores,
la estructura de datos que representa al al archivo.
BussinesDelegate Esta clase sirve como puente de comunicación entre las
capas de interfaz y control. Se encarga también de validar que la comunicación
entre estas capas se haga de forma correcta.
18
5. Módulo de consultas
Dentro del proceso de investigación en cual se enmarca este trabajo secon-
templa la recopilación de datos con el objetivo de usar el conocimiento de los ex-
pertos para correlacionar las diferentes variable que conforman el cuadro cĺınico
de los pacientes estudiados en búsqueda de resultados que puedan llevar a la
formulación de una hipótesis.
Para esto es necesario que los expertos estén en capacidad de definir difer-
entes consultas que les permitan obtener resultado significativos dentro de la
investigación. El proceso de definición de consultas es simple y no esta atado al
modelo de datos general del proyecto.
5.1. Consideraciones de diseño
Al diseñar el módulo de consultas se tiene que tener en cuenta muchos as-
pectos tanto funcionales como técnicos que resultan de vital importancia para
que el módulo de consultas de el apoyo investigativo que los expertos esperan
de el. Los aspectos más importantes de este diseño se muestran a continuación.
5.1.1. Consideraciones de funcionalidad
Los principales requerimientos funcionales del módulo de consultas son:
Permite consultas paralelas El módulo permite el despliegue de más de
una consulta al tiempo.
Condiciones de filtro de las consultas Las consultas aceptan más de una
condición lógica de filtrado. Estas condiciones son igualdad, desigualdad, mayor
que y menor que.
Soporta diferentes formas de despliegue El módulo soporta diferentes
formas de mostrar los resultados de las consultas. Estas formas son tabla, gráfica
de barras, gráfica de dispersión y modo por defecto.
Cruce de información El módulo permite cruzar la información de más de
un examen.
19
Proyección de consultas En la definición de consultas se permite hacer
proyecciones sobre los campos de los exámenes seleccionados para hacer la con-
sulta. Esto se hace para que se muestren en pantalla solo los campos que el
usuario considere necesarios para la consulta.
5.1.2. El formato de definición
En vista de que las personas encargadas de definir las consultas no necesari-
amente tienen experiencia en este campo el formato de definición de consultas
es simple y carece de elementos técnicos que puedan confundir al usuario.
Las consultas son escritas en archivos de texto siguiendo el esquema de un
archivo de propiedades de la plataforma Java2. El usuario puede cargar estos
archivos en el sistema en cualquier momento.
5.2. Tipo de consultas soportadas
Las consultas que soporta el sistema son cruces de información básicos que
pueden ser filtrados con condiciones sobre los valores de los campos. Estas condi-
ciones se pueden aplicar contra valores estáticos o sobre valores de otros campos.
Las condiciones que soporta el módulo de consultas son:
igualdad (=)
diferencia (!=)
mayor que (>)
menor que (<)
De ser necesario, el sistema permite la definición de múltiples condiciones en
una consulta. En este caso las consultas se encaden en forma normal conjuntiva
plena[Men97, pagina 30].
5.2.1. Formato de consultas
titulo=<titulo>
como=<formato de salida>
que=<examen>.<campo>, <examen2>.<campo>
2para más información ver http://java.sun.com/javase/6/docs/api/java/util/Properties.html
20
donde=<examen>, <examen2>
CF0=<examen>.<campo>,=,<examen>.<examen2>.<campo>
C0=AND
CF1=<examen>.<campo>,=,<examen>.<examen2>.<campo>
El formato de consultas está conformado principalmente por 5 partes iden-
tificadas con etiquetas de propiedades.
titulo En esta etiqueta se especifica el titulo de la consulta.
como En esta etiqueta se especifica la forma en que se muestran los resultados
de la consulta.
Para más información sobre formatos de despliegue de consultas pase a la sección
5.2.3
que En esta etiqueta se especifica la proyección sobre los datos de la consulta.
Esto se hace especificando cuáles campos, y de cuál examen, se quieren desplegar
en los resultados. Si se hace algo de la forma <examen>.* se muestra toda la
información de dicho examen.
donde En esta parte se especifica el(los) examen(es) sobre los que se quiere
hacer la búsqueda.
Condiciones Las condiciones se especifican en etiquetas del tipo CFi donde
i es un consecutivo que empieza en 0.
Es posible especificar más de una condición y estas se encadenan en forma
normal conjuntiva, usando tags del tipo Cj como conectores (un conector puede
ser AND u OR). j es un consecutivo que empieza en 0 y se usa para unir las
condciones CF(j/2) y CF(j/2 + 1)
Por ejemplo, las condiciones
CF0=<examen>.<campo>,=,<examen>.<examen2>.<campo>
C0=AND
CF1=<examen>.<campo>,=,<examen>.<examen2>.<campo>
CF2=<examen>.<campo>,=,<examen>.<examen2>.<campo>
C1=OR
CF3=<examen>.<campo>,=,<examen>.<examen2>.<campo>
21
Son equivalentes a (CF0 ∧ CF1) ∧ (CF2 ∨ CF3).
5.2.2. Datos multivalor
Uno de los principales problemas afrontados en el diseño del módulo son los
datos multivalor ya que su navegacion es ficil de implementar dentro de la capa
de control cuando se cuentan con elementos estructurados en más de dos niveles
como se muestra en la grafica 7.
Figura 7: Modelo de datos multivalor
Para solucionar este problema el módulo de consultas soporta notación punto
profunda permitiendo hacer cosas del tipo
<examen>.<examen2>.<examen3>.<campo de examen3>
Esto le permite al usuario definir condiciones lógicas de filtrado sobre los
datos que se encuentran en el fondo de la jerarqúıa de información.
5.2.3. Formas de despliegue de los resultados
Los formatos de despliegue de resultados soportados por la aplicación son:
tabla: En este formato los resultados de la consulta se despliegan en una
tabla en la que existe una columna por cada campo especificado en la
parte que del archivo de consultas.
grafica: En este formato se muestra la gráfica que mejor se ajuste a los
campos especificados en la parte que del archivo de consultas. Si el que es
un campo de enumeración o rango se mostrara una gráfica de barras. Si
el que son dos campos con valores numéricos se mostrara una gráfica de
dispersión con todos los puntos retornados por la consulta.
22
normal: En este formato los resultados se muestran de la misma manera
en que se muestran los exámenes fuera del módulo de consultas. Se agregan
botones de apoyo para la navegación de resultados.
Figura 8: Formas de despliegue de los resultados de una consulta
5.3. Diseño del módulo
La gráfica 9 muestra la parte del diagrama de clases del sistema referente al
módulo de consultas.
Figura 9: Diagrama de clases referente al módulo de consultas
La clase central es DesktopConsulta ya que esta es la encargada del manejo
de interacción con el usuario. Esta clase se comporta como un desktop, lo que sig-
nifica que permite desplegar mucho elementos al mismo tiempo y tratarlos como
si estos fueran ventanas internas (permite minimizar, restaurar y maximizar).
Las clases FrameConsultaGrafica, FrameConsultaTabla y FrameConsultaCampos
se usan para representar los diferentes tipos de formato de salida soportados por
23
el sistema. La comunicación con la clase BusinessDelegate (véase sección 4.4
en la pagina 17) es responsabilidad de cada una de esta clases.
El modulo de control toma los archivos de definición de consultas y los pasa
por un proceso de parsing para que puedan ser procesador por Hibernate.
No sobra recordar que este trabajo se limita a la capa de interfaz del sis-
tema, y por lo tanto no se hacen comentarios acerca de el procesamiento de las
consultas, lo cual es responsabilidad de la capa de control.
24
6. Implementación de la solución
Las decisiones de implementación juegan un papel muy importante el de-
sempeño del sistema y en su capacidad evolutiva. Es por eso que es importante
hablar de los detalles más relevantes de la implementación del sistema incluyen-
do algo de información sobre las capas de control y persistencia.
6.1. Base tecnológica
Las 3 capas del sistema están desarrollas en java 5.0.
El sistema basa sus capas de control y persistencia en tecnoloǵıas EJB
3.0[Sun06] de Sun Microsystems y en Hibernate 3.2[JBoa].
La tecnoloǵıa EJB 3.0 se usa para cumplircon el requerimiento de distribu-
ción, mientras que Hibernate se encarga de toda la persistencia del sistema,
incluyendo el procesamiento de consultas.
Estas capas corren sobre un servidor de aplicaciones JBoss 4.0.4.GA[JBob].
La base de la capa de interfaz es Java Swing[Sun05] el cual pertenece al
JFC[Sun] (Java Fundation Classes). Se toma esta decisión basándonos en la
facilidad de uso de Swing y el conocimiento previo que se tiene de esta tec-
noloǵıa[Gri06, Sección 4.3].
Para el despliegue de calendarios y fechas se usa JCalendar[Toe06], el cual es
un componente gráfico externo a Swing que tiene un esquema de licenciamiento
GPL[Fre91] (General Public Licence)
El modulo de consultas se desarrolla apoyándose en gran medida en JFreeChart
[Gil06] [Gil05] [Gri06, Sección 4.2], que es usado para generar las gráficas de bar-
ras y de dispersión que se usan para desplegar los resultados de las consultas.
JFreeChart también tiene licenciamiento GPL.
6.2. Implementación de componentes visuales
A continuación se muestra la forma en que se implementan visualmente cada
una de las entidades involucradas en el sistema.
25
6.2.1. Representación gráfica de un examen
Un examen se representa gráficamente como una pestaña:
Figura 10: Representación gráfica de un examen
En la gráfica se muestran todos los exámenes definidos por los expertos, y solo
se muestran los campos del examen seleccionado. En este caso es Información
Paciente3.
En examen es representado por una pestaña con el nombre del examen.
Dentro del panel del examen están los paneles que representan a cada uno de
los campos que conforman el examen.
6.2.2. Representación gráfica de los campos
Un campo se representa por un panel simple. En el borde del panel se escribe
el nombre del campo.
En la figura 11 se resalta el campo “genero” dentro del examen “Información
Paciente”.
Dependiendo del tipo de información que maneje el campo su representación
puede variar. Esto hace necesario incluir elementos gráficos como calendarios,
listas y gráficas para representar los diferentes tipo de información con los que
estamos lidiando.
3Para ver la definición de este exámen pase al apéndice A
26
Figura 11: Representación gráfica de un campo
6.2.3. Los diferentes tipos de campos
Campos tipo fecha La figuras 12 muestra el diseño de visualización de un
campo que representa una fecha. Inicialmente el campo se ve como un cuadro
de texto normal, pero al hacer click en el icono de calendario se despliega un
componente visual que permite escoger la fecha de una forma más interactiva.
Figura 12: Ingreso de una fecha
El despliegue se hace con un cuadro de texto simple que indica la fecha
ingresada en el sistema.
27
Campos tipo enumeración Un campo de enumeración es representado por
una lista en la cual cada item representa una de las opciones definidas en el
archivo de definición de información por parte de los expertos.
La figura 13 muestra el diseño visual de un campo que exprese informa-
ción enumerada. Este tipo de campo es útil para información con una cantidad
discreta de opciones tales como genero, estado civil, etc.
Figura 13: Ingreso de un dato enumerable
El despliegue de este tipo de campos se hace con un cuadro de texto simple
indicando la opción ingresada por en el sistema.
Campos tipo rango Los campos de tipo rango se muestran, al momento
del ingreso de información, con una lista similar a la de los campos de enu-
meraciones. Cada item en la lista representa uno de los rangos definidos por los
expertos y se muestra la descripción del rango y los valores de sus limites.
Figura 14: Ingreso de un campo tipo rango
La información de campos tipo rango se despliegan en un cuadro de texto
28
Figura 15: Despliegue de un campo tipo rango
Figura 16: Gráfica representativa de un rango
simple como lo muestra la figura 15. Al hacer click en el botón Ver grafico se
muestra una gráfica que representa todos los rangos definidos para ese campo y
ubica el dato actual en los estos rangos tal y como lo muestra la figura 16. Los
colores de los rangos son definidos por el experto.
Campos tipo valor absoluto Los campos de valor absoluto se muestran,
en despliegue e ingreso, con cuadros de campos simples. Ademas de esto se
muestran los limites aceptados para el valor a ingresar y las unidades del dato.
Campos para archivos Los campos de archivos se muestran, en ingreso, con
un cuadro de texto simple y un botón que da la opción de buscar el archivo a
ingresar. En despliegue estos campos se muestran con un cuadro de texto simple
con la ruta del archivo guardado.
Campos generales Para la representación de campos generales o que no se
ajusten a ninguno de los tipos de campos anteriormente descritos se usa un
29
Figura 17: Forma de ingreso y despliegue de un dato de valor absoluto
Figura 18: Ingreso de un campo de archivo
cuadro de texto simple tanto en ingreso como en despliegue.
30
7. Análisis de resultados
El sistema construido es un sistema capas de adaptarse a las necesidades
informáticas expresadas por los expertos de forma ágil cumpliendo aśı su ob-
jetivo principal. Con esto se logra dar una mayor libertad a los expertos a la
hora de modificar la definición de la información que manejan y se brinda una
gran flexibilidad a la hora de correlacionar esta información con el modulo de
consultas. Pese a esto los expertos expresaron dificultades durante el proceso de
normalización de la información.
El modulo de consultas y la facilidades de definición de consultas que este
brinda son de gran ayuda en procesos investigativos. El éxito de este modulo
radica en la gran cantidad de formas y tipos consultas que soporta, aun cuando
esto agregue complejidad al formato de definición de consultas.
El formato de consultas resulta, en un principio, un poco confuso para los
expertos, pero su manejo se hace sencillo una vez se haya superado la curva de
aprendizaje y se tenga un poco de practica en este.
Sin embargo, decisiones de diseño e implementación apresuradas a causa de
la premura del tiempo hacen que la aplicación sea dif́ıcil de adaptar a contextos
ajenos al que se maneja dentro del proyecto. Es notable la poca flexibilidad
que tiene el archivo de definición de información y no se brinda ninguna fun-
cionalidad para definir vista o pantallas sobre la información definida. tampoco
se soportan modificaciones sobre la interfaz gráfica del sistema o perfiles de
usuarios.
Todo esto debe tomarse en cuenta para una futura versión del sistema.
31
8. Conclusiones y trabajo futuro
Este trabajo demuestra que es factible construir software en el que se de-
sacopla totalmente la información o el modelo de datos a manejar de los requer-
imientos funcionales y no funcionales del sistema.
Es importante modelar el software como concepto para poder encontrar los
puntos de acople entre el modelo de datos y los requerimientos funcionales para
aśı poder aislarlos y hacer que el modelo sea reemplazable sin afectar el resto
de la aplicación. Todo esto debe concentrarse en cierto tipo de aplicaciones
y cierto tipo de requerimientos funcionales para lograr tener una base solida
sobre la que se puedan agregar nuevas funcionalidades y soportar nuevo tipo de
requerimientos y entidades.
Para una futura versión es importante tener en cuenta los siguientes puntos:
Modela el software como concepto.
Evaluar la posibilidad de integrar de manera incremental nuevos requer-
imientos al software
Separar la definición de entidades de la definición de vistas o perspectivas
sobre estas entidades.
Usar un formato de definición de entidades más flexible y, de ser posible,
que sea un estándar abierto.
Definir una arquitectura que haga fácil el proceso de agregar un nuevo
tipo de requerimiento o entidad.
Explorar la posibilidad de hacer que el sistema sea una aplicación web
32
Referencias
[ANU+05] J.A. Arias, E.M. Nieto, L.F. Uriza, M. Hernández Hoyos
y J.C. Briceño. Effectof stenosis severity and blood viscosity
on platelet activation index: a computacional study on a 2d carotid
bifurcation. En “Summer Bioengineering Conference”, Colorado,
USA (Junio 2005).
[Fre91] Free Software Fundation. “GNU General Public License” (1991).
http://www.gnu.org/copyleft/gpl.html.
[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson y John Vlis-
sides. “Design Patterns: Elements of Reusable Object-Oriented
Software”. Addison-Wesley Professional Computing Series. Addison-
Wesley (1995).
[Gil05] David Gilbert. “The JFreeChart Developer Guide” (2005).
[Gil06] David Gilbert. “JFreeChart” (2006).
[Gri06] Julian Eduardo Grijalba. Desarrollo de una interfaz dinamica
basada en descriptores. Universidad de los Andes (2006).
[JBoa] JBoss organization. “Hibernate”. http://www.hibernate.org/.
[JBob] JBoss organization. “JBoss application server”.
http://labs.jboss.com/portal/jbossas/?prjlist=false.
[JGJ+06] Claudia Jimenez, Julian Grijalba, Camilo Jimenez,
Sergio Moreno y Juan Gómez. Software construc-
tion for evolving systems with incomplete information def-
inition. En “XML conference 2006” (Noviembre 2006).
http://2006.xmlconference.org/proceedings/155/slides-jimenez.pdf.
[Men97] E. Mendelson. “Introduction to Mathematical Logic”. Chapman
and Hall, 4ta edición (1997).
[Pro] Proyecto de investigación ECOS. “Análisis interactivo y almace-
namiento distribuido de imágenes médicas 3D”. Proyecto europeo
código C03S02 2004.
[Sun] Sun Microsystems. “Java Fundation Classes”.
http://java.sun.com/products/jfc/reference/index.html.
[Sun05] Sun Microsystems. “Swing. Java Fundation Classes” (2005).
http://java.sun.com/javase/6/docs/technotes/guides/swing/index.html.
[Sun06] Sun Microsystems. “EJB 3.0 Technology FAQ” (2006).
http://java.sun.com/javaee/overview/faq/ejb.jsp.
33
[Toe06] Kai Toedter. “JCalendar” (2006).
http://www.toedter.com/en/jcalendar/.
[UAN+04] L.F. Uriza, J.A. Arias, E.M. Nieto, M. Hernández Hoyos y
J.C. Briceño. Desarrollo de un modelo computacional para estudio
de la enfermedad artiosclerótida carot́ıdea. En “XXXIX Congreso
Nacional de Radioloǵıa”, Cartagena, Colombia (Octubre 2004).
34
Apendices
A. Ejemplo de archivo de definición de informa-
ción
<Paciente>
<Serie>
<Examen nombre=‘‘Informacion Serie’’>
<campo nomcampo=‘‘Descripcion’’>
<descripcioncampo/>
<obligatorio>si</obligatorio>
<tipocampo>texto</tipocampo>
</campo>
<campo nomcampo=‘‘Fecha realizacion’’>
<descripcioncampo/>
<obligatorio>si</obligatorio>
<tipocampo>fecha</tipocampo>
</campo>
<campo nomcampo=‘‘Fecha ingreso’’>
<descripcioncampo/>
<obligatorio>si</obligatorio>
<tipocampo>fecha</tipocampo>
</campo>
<campo nomcampo=‘‘Ubicacion’’>
<descripcioncampo/>
<obligatorio>si</obligatorio>
<tipocampo>archivo</tipocampo>
</campo>
<campo nomcampo=‘‘Tipo’’>
<descripcioncampo/>
<obligatorio>si</obligatorio>
<tipocampo>texto</tipocampo>
<tipovalor>
<enumeracion>
<valores>
<valor>0</valor>
<significado>EcoDoppler</significado>
</valores>
<valores>
<valor>1</valor>
<significado>ASD</significado>
</valores>
<valores>
<valor>2</valor>
<significado>AngioResonancia</significado>
</valores>
<valores>
<valor>3</valor>
<significado>AngioEscanografı́a</significado>
</valores>
<valores>
<valor>4</valor>
35
<significado>Eco Modo B</significado>
</valores>
</enumeracion>
</tipovalor>
</campo>
</Examen>
</Serie>
</Examen>
<Examen nombre=‘‘Informacion paciente’’>
<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>
</campo>
<campo nomcampo=‘‘Nombre’’>
<descripcioncampo/>
<obligatorio>si</obligatorio>
<tipocampo>texto</tipocampo>
</campo>
</Examen>
<Examen nombre=‘‘Laboratorios’’>
<campo nomcampo=‘‘Fecha ingreso’’>
<descripcioncampo/>
<obligatorio>si</obligatorio>
<tipocampo>fecha</tipocampo>
</campo>
<campo nomcampo=‘‘Fecha realizacion’’>
<descripcioncampo/>
<obligatorio>si</obligatorio>
<tipocampo>fecha</tipocampo>
</campo>
<campo nomcampo=‘‘Tension arterial sistolica’’>
<descripcioncampo/>
<obligatorio>si</obligatorio>
<tipocampo>entero</tipocampo>
<tipovalor>
<rango limINF=‘‘0’’ limSUP=‘‘300’’ ejeX=‘‘mm Hg’’ ejeY=‘‘’’>
<valoresRango>
<valorRango>120</valorRango>
<significadoRango>Normal</significadoRango>
36
<colorRango>GREEN</colorRango>
</valoresRango>
<valoresRango>
<valorRango>140</valorRango>
<significadoRango>Prehipertension</significadoRango>
<colorRango>YELLOW</colorRango>
</valoresRango>
<valoresRango>
<valorRango>160</valorRango>
<significadoRango>HTA estadio 1</significadoRango>
<colorRango>ORANGE</colorRango>
</valoresRango>
<valoresRango>
<valorRango>259</valorRango>
<significadoRango>HTA estadio 2</significadoRango>
<colorRango>RED</colorRango>
</valoresRango>
</rango>
</tipovalor>
</campo>
<campo nomcampo=‘‘Tension arterial diastolica’’>
<descripcioncampo/>
<obligatorio>si</obligatorio>
<tipocampo>entero</tipocampo>
<tipovalor>
<rango limINF=‘‘0’’ limSUP=‘‘200’’ ejeX=‘‘mm Hg’’ ejeY=‘‘’’>
<valoresRango>
<valorRango>80</valorRango>
<significadoRango>Normal</significadoRango>
<colorRango>GREEN</colorRango>
</valoresRango>
<valoresRango>
<valorRango>90</valorRango>
<significadoRango>Prehipertension</significadoRango>
<colorRango>YELLOW</colorRango>
</valoresRango>
<valoresRango>
<valorRango>100</valorRango>
<significadoRango>HTA estadio 1</significadoRango>
<colorRango>ORANGE</colorRango>
</valoresRango>
<valoresRango>
<valorRango>200</valorRango>
<significadoRango>HTA estadio 2</significadoRango>
<colorRango>RED</colorRango>
</valoresRango>
</rango>
</tipovalor>
</campo>
</Examen>
</Paciente>
37
B. Ejemplo de archivo de relaciones
<configrelaciones>
<identificadores>
<identificador nombreExamen=‘‘Informacion Serie’’ tipo=‘‘autogenerado’’/>
<identificador nombreExamen=‘‘Analisis Clinico’’ tipo=‘‘autogenerado’’/>
<identificador nombreExamen=‘‘AngioEscanografia’’ tipo=‘‘autogenerado’’/>
</identificadores>
<relaciones>
<relacion nombreExamen=‘‘Informacion paciente’’>
<one-to-many nombreExamenDestino = ‘‘Analisis Clinico’’ columnaOrigen = ‘‘cedulaçolumnaDestino
= ‘‘idPaciente’’/>
</relacion>
<relacion nombreExamen=‘‘Informacion paciente’’>
<one-to-many nombreExamenDestino=‘‘AngioEscanografia’’ columnaOrigen=‘‘cedula’’
columnaDestino=‘‘idPaciente’’/>
</relacion>
<relacion nombreExamen = ‘‘Informacion Serie’’>
<one-to-many nombreExamenDestino=‘‘AngioEscanografia’’ columnaOrigen=‘‘fecharealizacion’’
columnaDestino=‘‘fecharealizacion’’/>
</relacion>
</relaciones>
</configrelaciones>
38