UNIVERSIDAD NACIONAL DE TUCUMN FACULTAD DE CIENCIAS EXACTAS DE Y TECNOLOGA ELECTRICIDAD,

DEPARTAMENTO

ELECTRNICA Y COMPUTACIN

Trabajo de Graduacin - Informe Final

MTODO FLEXIBLE DE PERSISTENCIA DE OBSERVACIONES CLNICAS

Autor : Darwin Rodrigo Zottola Pareja CX1015599 Ingeniera en Computacin Plan 2004

Tutor: Ing. Solarz, Pablo Federico

Instituto de Bio Electrnica

Co Tutor : Ing. Steifensand, Jorge

Tucumn Diciembre 2012

A mi madre por su ejemplo de vida. A mis hermanos por el apoyo constante. A mi esposa y mis hijos por su paciencia, por su eterna fe en mi y sobre por el tiempo que les he robado.-

Agradecimientos

Agradezco en primer lugar a Dios y la virgen por darme la oportunidad de llegar hasta ac, agradezco por su colaboracin en este trabajo a profesores, en especial al ingeniero Pablo Solarz, al IBE (Instituto de Bio Electrnica) y las personas que trabajan en l, amigos, familia y todos los que de una manera u otra pusieron una cuota desinteresada para ayudar a terminar este proyecto.

Contenido
Agradecimientos ....................................................................................................................... 3 Contenido ................................................................................................................................. 4 ndice de imgenes ................................................................................................................... 7 ndice de Diagramas.................................................................................................................. 8 ndice de Cdigo Fuente............................................................................................................ 9 Resumen................................................................................................................................. 10 Glosario .................................................................................................................................. 11 1 INTRODUCCION............................................................................................................... 12 1.1 1.2 PROBLEMTICA - MOTIVACIONES............................................................................ 12 OBJETIVOS ............................................................................................................... 14 Objetivos Principal ........................................................................................... 14 Objetivos generales ......................................................................................... 14

1.2.1 1.2.2 2

APLICACIN WEB PARA TELEMEDICINA CHASQUI ........................................................... 17 2.1 2.2 2.3 2.4 2.5 2.6 2.7 ARQUITECTURA ....................................................................................................... 17 TECNOLOGIAS ACTUALES ........................................................................................ 18 MODELO FUNCIONAL .............................................................................................. 18 PROBLEMTICA ACTUAL .......................................................................................... 20 OBSERVACIONES CLNICAS COMO INFORMACIN ................................................... 21 EL MODELO DE BASE DE DATOS RELACIONAL Y SU PROBLEMTICA ........................ 23 ANALISIS DE ESTADO ............................................................................................... 24 Puntos Crticos: ................................................................................................ 24 Puntos Fuertes ................................................................................................. 24

2.7.1 2.7.2

3 METODO FLEXIBLE DE PERSISTENCIA DE OBSERVACIONES CLINICAS FUNDAMENTOS TERICOS ............................................................................................................................... 25 3.1 CAMBIO DE ARQUITECTURA CAPA DE DATOS ....................................................... 25 XML ................................................................................................................. 25 TECNOLOGIAS PARA LA MANIPULACION Y DESARROLLO DE XML ..................... 31

3.1.1 3.1.2 3.2

CAMBIO DE ARQUITECTURA CAPA DE INTEGRACION ............................................ 34 JDOM ............................................................................................................... 34 METHOD CORE................................................................................................. 36

3.2.1 3.2.2 4

CONCEPTOS INVOLUCRADOS .......................................................................................... 38 4.1 PATTERNS - PATRONES DE DISEO .......................................................................... 38 DAO- DTO ........................................................................................................ 38 4

4.1.1

4.2

PATRONES GOF........................................................................................................ 38 ABSTRACT FACTORY ......................................................................................... 38 FACTORY METHOD ........................................................................................... 39 PROTOTYPE ...................................................................................................... 39

4.2.1 4.2.2 4.2.3 4.3

PATRONES DE ARQUITECTURA ................................................................................ 40 MVC ................................................................................................................. 40 Arquitectura en n capas ................................................................................... 40

4.3.1 4.3.2 4.4

FRAMEWORKS J2EE ................................................................................................. 42 JSF JAVA SERVER FACE................................................................................... 42 ICEFACES.......................................................................................................... 43

4.4.1 4.4.2 5

METODO FLEXIBLE APLICACIN PASO A PASO ................................................................ 44 5.1 5.2 5.3 Paso 1 Diseo de la estructura de los datos en formato de texto -CAPA DE DATOS .. 45 Paso 2 Creacin de una clase DTO ........................................................................... 48 Paso 3 Parseo y Serializacin Capa de Integracin ................................................. 49 METODO PARSE() ............................................................................................. 50 METODO SERIALIZE() o Serializacin ................................................................ 51

5.3.1 5.3.2 5.4

Paso 4 Persistencia en la base de datos - Capa de Integracin ................................ 52 Guardar en la Base de Datos ............................................................................ 53 Modificar una observacin en la Base de datos ................................................ 53 Eliminar y obtener Observacin ....................................................................... 54

5.4.1 5.4.2 5.4.3 5.5

METODO GENERALIZADO ........................................................................................ 55 Herencia .......................................................................................................... 55 Encapsulamiento ............................................................................................. 56

5.5.1 5.5.2 5.6 5.7

OBSERVACIONES CLNICAS....................................................................................... 57 APLICACIN DE INTERFACES .................................................................................... 59 INTERFACES Iparseable.................................................................................. 59 INTERFACES IAnalizable ................................................................................. 60

5.7.1 5.7.2 5.8

IMPLEMENTACION DEL PATRN FACTORY............................................................... 62 FACTORY AnalizerFactory .............................................................................. 62 FACTORY TemplateFactory ............................................................................ 63

5.8.1 5.8.2 5.9

IMPLEMENTACION DEL PATRN DAO ...................................................................... 65 INTERFACES IObservationDAO....................................................................... 65

5.9.1 5.10 5.11

DIAGRAMA DE CLASES ............................................................................................. 69 CONCLUSIONES DE LA GENERALIZACIN ................................................................ 69 5

ESCALABILIDAD ............................................................................................................... 71

CONCLUSIONES ............................................................................................................... 73

BIBLIOGRAFIA.................................................................................................................. 74

ndice de imgenes

Figura 1. Arquitectura Prototipo Web ____________________________________________________ 17 Figura 2. Modelo Funcional de Prototipo Web _____________________________________________ 18 Figura 3. Procesos al subir archivo a la BD ________________________________________________ 19 Figura 4. Procesos para compartir los documentos multimedia. _______________________________ 20 Figura 5. Presin sangunea segn openEHR .______________________________________________ 21 Figura 6.Temperatura corporal segn openEHR . ___________________________________________ 22 Figura 7. Representacin relacional de una Observacin _____________________________________ 23 Figura 8. Agregacin de una nueva observacin a DB relacional _______________________________ 23 Figura 9.Impacto en las capas de la Arquitectura ___________________________________________ 24 Figura 10. Observacin como atributo TEXT _______________________________________________ 26 Figura 11. Gramtica XML _____________________________________________________________ 29 Figura 12. Validacin de un XML ________________________________________________________ 31 Figura 13. Parsing BloodPressure _______________________________________________________ 31 Figura 14. Cambio en Arq. Nueva Capa integracion _________________________________________ 34 Figura 15. JDOM Pack Structure ________________________________________________________ 35 Figura 16. Arquitectura en n capas ______________________________________________________ 41 Figura 17 Tabla Observaciones________________________________________________________ 44 Figura 18 Estados de una observacin usuario a DB _______________________________________ 45 Figura 19 - Estados de una observacin DB a Usuario ______________________________________ 45 Figura 20 Capa de Datos + Integracin__________________________________________________ 45 Figura 21 BloodPressure Structure OPENEHR_____________________________________________ 46 Figura 22 BodyTemperature OPENEHR __________________________________________________ 57 Figura 23 - BodyTemperature version reducida.____________________________________________ 57 Figura 24 -Se puede crear una relacin directa entre las vistas y las estructura y combinar las vistas segn sea necesario. _________________________________________________________________ 72

ndice de Diagramas
Diagrama 1 Analizer Class.................................................................................................................. 50 Diagrama 2 Interface IParseable ........................................................................................................ 60 Diagrama 3 Interface IAnalizable ....................................................................................................... 61 Diagrama 4 Analizer Factory .............................................................................................................. 63 Diagrama 5 Template Factory ............................................................................................................ 64 Diagrama 6 - ObservationDAO .............................................................................................................. 65 Diagrama 7 Diagrama de clases MethodCore ..................................................................................... 69

ndice de Cdigo Fuente

Cdigo 1 BloodPressure Empty ........................................................................................................... 27 Cdigo 2 BloodPressure Schema......................................................................................................... 29 Cdigo 3 - BloodPressure XML Template ............................................................................................... 47 Cdigo 4 BloodPressure.xsd................................................................................................................ 48 Cdigo 5 ObservationDTO.Java .......................................................................................................... 49 Cdigo 6 Iparseable.Java.................................................................................................................... 51 Cdigo 7 Metodo Serealize() .............................................................................................................. 52 Cdigo 8 AddObservatinDB() .............................................................................................................. 53 Cdigo 9 updateObservationDB() ....................................................................................................... 54 Cdigo 10 deleteObservationDB()....................................................................................................... 54 Cdigo 11 getObservation() ............................................................................................................... 55 Cdigo 12 BodyTemperature.xml ....................................................................................................... 58 Cdigo 13 BodyTemperature.xsd ........................................................................................................ 58 Cdigo 14 BodyTemperature DTO ...................................................................................................... 60 Cdigo 15 Implements IAnalizable...................................................................................................... 61 Cdigo 16 Contrato de IAnalizable...................................................................................................... 62 Cdigo 17 - AnalyzeFactory.java ........................................................................................................... 63 Cdigo 18 - Template Factory .............................................................................................................. 64 Cdigo 19 - IObservationDTO ................................................................................................................ 66 Cdigo 20 - ObservationDAO ................................................................................................................ 66 Cdigo 21 ObservationDAOImp .......................................................................................................... 68

Resumen
El siguiente trabajo propone mtodo de persistencia de informacin, flexible y dinmico, y su aplicacin en un Prototipo Web para Telemedicina, desarrollado como parte de un proyecto que busca generar una red de telemedicina para el Sistema Provincial de Salud de la Provincia de Tucumn. La actual arquitectura de software, que contiene un modelo puramente relacional en su capa de persistencia, presenta en particular el inconveniente de que la gestin y administracin de la informacin referente a observaciones clnicas, que se caracterizan por una gran variabilidad en su estructura y tipo de datos, implica un nuevo diseo e implementacin del esquema de datos cada vez que se ingresa un nuevo tipo de observacin, impactando en el resto de las capas de la arquitectura ante lo cual dicho mtodo propone formas alternativas al manejo actual de la informacin dentro del sistema representando observaciones clnicas con estructuras en lenguaje XML, y que sirven adems de base a la capa de presentacin. De esta manera, nuevos tipos de observaciones clnicas tienen que ver con agregar el modelo correspondiente en XML y su presentacin, impactando mnimamente en la arquitectura. Logrando as soluciones basadas en software libre, otorgando flexibilidad a la hora de crear y visualizar las estructuras, facilitando su manejo y el mantenimiento del sistema total.

Palabras Claves: Telemedicina informtica medica aplicaciones web XML Parsers Java J2EE Icefaces POO

Glosario
OBSERVACIONES MDICAS: SERIALIZACIN: La serializacin consiste en un proceso de codificacin de un objeto en un medio de almacenamiento (como puede ser un archivo, o un buffer de memoria) con el fin de transmitirlo a travs de una conexin en red como una serie de bytes o en un formato humanamente ms legible como XML o JSON, entre otros.

11

CAPITULO 1 INTRODUCCION
1 INTRODUCCION
EL proyecto de telemedicina en Tucumn [1], hoy bautizado como CHASQUI surge en base a la existencia de numerosos centros asistenciales de diversa complejidad que pertenecen al Sistema Provincial de Salud de Tucumn (SIPROSA) y se encuentran dispersos en el interior de la provincia. En dichos centros existe un aprovechamiento deficiente de los recursos fsicos y humanos, as como la mala difusin de los servicios que se prestan y la falta de mdicos especialistas, ocasionando la generacin de un importante nmero de derivaciones innecesarias hacia los centros de mayor complejidad. La Organizacin Mundial de la Salud (OMS), define a la Telemedicina como: El suministro de servicios de atencin sanitaria, en los que la distancia constituye un factor crtico, por profesionales que apelan a las tecnologas de la informacin y de la comunicacin con objeto de intercambiar datos para hacer diagnsticos, preconizar tratamientos y prevenir enfermedades y heridas, as como para la formacin permanente de los profesionales de atencin de salud y en actividades de investigacin y evaluacin, con el fin de mejorar la salud de las personas y de las comunidades en que viven. [2]. En base a esto hoy el Proyecto Telemedicina en Tucumn desarrolla de una red telemdica multimedia que permita la comunicacin entre centros asistenciales rurales, hospitales centrales y agentes de salud en general. En l se desarrolla software que permite bsicamente virtualizar las interconsultas mdicas haciendo uso de herramientas multimedia para permitir usar todos los elementos de diagnstico: imgenes (Rx, Ecografas), videos (ecocardiogramas), Audio (Auscultaciones desde estetoscopios electrnicos), texto (Resultados de anlisis, informes, etc.). Adems de la comunicacin entre los agentes mediante audio, video, chat, tanto on-line como off-line.

1.1 PROBLEMTICA - MOTIVACIONES

Para desarrollar las prestaciones de una aplicacin web que otorgue servicios para crear una comunicacin multimedia en aplicaciones para telemedicina, hace que cualquier

desarrollo de este tipo requiera retos en cuanto a la representacin digital de la informacin mdica ya sea en diseos, implementacin y sobre todo en la organizacin de los datos y su persistencia. Es entendible que para una comunicacin de este tipo se requiere una gran cantidad de datos que deber ser recibida por el usuario y manipulada por el mismo a travs de la aplicacin. El modelo de datos relacional planteado para el prototipo web de telemedicina tiene resueltos muchos de los aspectos sobre la gestin de datos de informacin anloga a la procesada por los sistemas de gestin en general, pero aun siendo tan fuerte este diseo posee puntos dbiles en cuanto a la representacin de la informacin especficamente de las Observaciones Clnicas. La necesidad surge del problema que tienen los modelos actuales de gestin de base de datos para satisfacer necesidades en sistemas mdicos debido a la diversidad de los tipos de Observaciones mdicas y con ello no solo diversidad de tipo de datos si no lo mas importante la diversidad en las estructuras Observaciones [3]. que son necesarias formar para cado uno de estas

Dichas observaciones no solo poseen una familia muy grande de tipos que necesitan ser manipulados si no que sus estructuras a la hora de ser representadas fehacientemente dentro de un modelo relacional puede variar desde estructuras muy simples que se resumen a una entidad, como relaciones complejas de varias de ellas y su respectiva cardinalidad u ocurrencias. A todo esto podramos sumar el hecho que su crecimiento en cuanto a cantidad de tipos y la variacin de sus estructura basadas en actualizaciones o nuevas investigaciones son significativamente variables en la lnea de tiempo, lo que demuestra que no se trabaja con estructuras estables y estticas, - Haciendo referencia al modelo relacional completo - sino todo lo contrario. Esto hace que su administracin se vuelva compleja y sobre todo que la agregacin o eliminacin de alguna de ellas significa un impacto en el sistema, ya que se deber hacer un rediseo de la base de datos y por ende esto producir un efecto domino afectando cada una de las capas de la arquitectura de la aplicacin. Un ejemplo seria el listar observaciones como presin sangunea, temperatura corporal , una ecografa, un electrocardiograma, etc.; cualquier observacin de este tipo puede llegar a poseer datos tan sencillos como el saber cul sera el valor de presin alta y cual el valor de la baja, o datos complejos como analizar los puntos de una imagen de alta calidad para dar un diagnsticos dermatolgico y tal vez el procesar la informacin de una electrocardiograma, y 13

esto en base a la precisin que se busque en los resultados, comprendiendo as que esta complejidad puede crecer considerablemente. De Esta manera tenemos una estructura de datos que conforme cuan especfico se desee a este estudio puede crecer a un tamao considerable. La misma que deber luego ser agregada a nuestra base de datos. Existirn otras observaciones que poseern igual, menor o mayor tamao en su estructura, y sobre todo que sern de estructura diversas y complemente diferentes. Esto implicara no solo modificar el diseo de la base de datos, si no hacer las debidas modificaciones en las diferentes capas, la de negocios, la de aplicacin etc. de esta manera este sera el procedimiento cada vez que se agregue un nuevo tipo de observacin.

1.2 OBJETIVOS
1.2.1 Objetivos Principal objetivo de este proyecto se basa en Implementar una metodologa de En primer el

Persistencia de informacin (sobre observaciones clnicas), que sea flexible, dinmica y hacer factible su futura aplicacin sobre el prototipo web para telemedicina Chasqui. 1.2.2 Objetivos generales

Lo que desencadenara en el cumplimiento de objetivos secundarios tales como: Mejorar la administracin (flexibilidad a la hora de crear, modificar y borrar una observacin clnica). Reducir el impacto en cada capa de la Arquitectura del Sistema. Mejorar el mantenimiento y la reutilizacin del cdigo. Simplificar el trato de la informacin en las distintas capas hasta su presentacin al usuario.

En otras palabras afectar mnimamente las capas de la arquitectura por cada inclusin de las nuevas estructura, buscando soluciones para cada una de ellas o para todas en conjunto. Crear una metodologa en la cual nos independicemos del modelo relacional sin perder sus beneficios pudiendo mantener la coherencia de los datos y su combinacin y con el sistema inicial actuando ambos como uno solo. Permitir el crear diversas observaciones clnicas en forma de estructuras de datos e insertarlas dentro del modelo relacional preexistente, independizarme del modelo relacional en cuanto a la gestion; y que la nueva estructura creada sea flexible en su creacin y modificacin, impactando mnimamente en la estructura de datos original. 14

Dicha metodologa constara de una serie de pasos que de cierta forma estandaricen o crean un proceso que pueda ser reproducido por cualquier desarrollador sin necesidad de una compleja capacitacin. Es decir la administracin de dicha informacin y que su desarrollo pueda ser repetido y reproducido, con el mnimo costo y una curva de aprendizaje corta.

15

CAPITULO 2 APLICACIN WEB PARA TELEMEDICINA CHASQUI

2 APLICACIN WEB PARA TELEMEDICINA CHASQUI
Agregando a lo antes expuesto se podra agregar que el objetivo de la aplicacin web para telemedicina es favorecer la calidad de las prestaciones de la salud pblica en los numerosos centros asistenciales que se encuentran dispersos en el interior de la provincia, disminuyendo el riesgo de toma de decisiones equivocadas y traslados innecesarios. Utilizando los servicios de Internet como soporte de comunicaciones entre agentes de la salud, tanto de zonas perifricas de las ciudades como de zonas rurales. En este captulo se analizara a fondo su arquitectura y problemticas.

2.1 ARQUITECTURA
La Figura 1 muestra un esquema de la arquitectura actual de la aplicacin de telemedicina.

Figura 1. Arquitectura Prototipo Web

En la misma distinguimos 4 capas: La capa de datos que es donde residen los datos y es la encargada de acceder a los mismos; la Base de Datos (BD) donde se almacenan los documentos multimedia, datos de pacientes y sus observaciones clnicas, agentes de salud colaboradores, etc. (Implementada con MySQL). La capa de negocios donde residen los programas que se ejecutan, es tambin donde se reciben las peticiones del usuario y se envan las respuestas tras el proceso. Estas reglas de negocios creadas en esta capa fueron

implementadas con lenguaje Java 1.6. La capa que se encuentra entre la capa de aplicacin y las vistas de navegador web, fue confeccionada con Java Server Faces (JSF) particularmente mediante el framework ICE Faces 1.8. Y por ltimo la capa de presentacin que es la que se comunica con el usuario final. Hoy en da estas tecnologas estn siendo migradas a nuevas versiones y actualizaciones de los respectivos frameworks y Apis con los que se trabaja.

2.2 TECNOLOGIAS ACTUALES

Actualmente las tecnologas utilizadas por la aplicacin son las siguientes: MySQL 5 JDK 1.6 J2EE JAVA ENTERPRISE EDITION JSF - JAVA SERVER FACE Icefaces 1.8 Glassfish Web Application Server

2.3 MODELO FUNCIONAL

Desde un punto de vista funcional, Internet es el elemento central que permite intercomunicar los diferentes actores desde diferente tipo de terminales, tanto fijas como mviles incluyendo el intercambio de texto, voz, imgenes, videos, etc. que dan soporte a los mtodos complementarios de diagnstico.

Figura 2. Modelo Funcional de Prototipo Web

Servidores de Internet, de aplicaciones y de bases de datos son necesarios para el funcionamiento y son los medios para llevar textos, imgenes, etc. a la web. Los actores tpicos del sistema son: Paciente y Agente Sanitario por el lado del Hospital rural, que requieren al sistema el servicio de asistencia entregando informacin sobre la dolencia del 18

paciente. Por otro lado el (o los) especialista(s), que desde hospitales centrales o desde cualquier dispositivo por el que pueda acceder a la web aporta sus conocimientos basado en el intercambio de informacin, para dar solucin al pedido original. Las caractersticas ms importantes de la aplicacin se las puede resumir a partir de 2 escenarios de uso: 1) Ingresar un archivo multimedia a la base de datos de la aplicacin para que quede disponible en conversaciones posteriores. Esta tarea se realiza: a. Ingresando datos del paciente relevantes (no necesariamente identificarlo)

b. Sealando en la interfaz la ubicacin del archivo. A partir de ah este es pasado por un analizador de formato, que interpreta de que tipo se trata, en base a los tipos registrados. Una vez analizado, lo procesa para cargarlo en la BD. En la Figura se muestra como el analizador de formato instancia el procesador adecuado para subirlo a la BD. Procesos al subir archivo a la BD:

Figura 3. Procesos al subir archivo a la BD

1) Colaboracin entre los actores compartiendo archivos. Esta tarea se realiza: a. Uno de los usuarios incorpora en la conversacin uno o ms archivos multimedia relacionados con el paciente, se observa como el analizador de formato lee el archivo, y se encarga de instanciar el panel correspondiente para ese formato en la interfaz web. 19

b. La aplicacin se encarga de replicar esta tarea en todos los usuarios colaboradores, permitindoles compartir la misma documentacin y c) Paralelamente tienen abierto el canal de chat para intercambiar opiniones.

Procesos para compartir los documentos multimedia:

Figura 4. Procesos para compartir los documentos multimedia.

2.4 PROBLEMTICA ACTUAL

La informacin generada en el entorno medico/sanitario es cuantitativamente colosal. Un claro indicador lo encontramos en el enorme volumen de sus archivos y en el ritmo acelerado con que stos crecen. Esta informacin es de naturaleza muy diversa. Puede existir informacin en las historias clnicas, en los diagnsticos o en los informes mdicos que pueden complicar en extremo la gestin de estas informaciones o dicha informacin en su totalidad transformarse ilegible, de difcil acceso, ambigua o exigua, lo que dificulta la creacin de soluciones en cuento a su representacin como datos digitales dentro de alguna aplicacin. Esto no siendo un problema general a nivel de cualquier sistema dentro del entorno mdico. Son diversos lo orgenes de la informacin mdica y en particular de las observaciones clnicas; pueden provenir del paciente, del profesional, dispositivos o de cada servicio, lo que supone la existencia de un gran nmero de formatos distintos que complican su manejo, y su persistencia en base de datos que pueden tornarse compleja sin la debida representacin y administracin. Esto pone en evidencia la diversidad de informacin que se debe administrar dentro de un sistema que contenga observaciones clnicas en forma de datos, otorgndole la

obligatoriedad de un cambio y adaptacin continua. Hablando sobre las historias clnicas y los diagnsticos apoyados en su contenido, un punto de quiebre es la existencia de una diversidad abundante y extensa en cuanto a las 20

observaciones clnicas, la informacin pertenecientes a las mismas y sobre todo en las estructuras usadas para representar las mismas; su constante adhesiones y /o transformaciones, hacer su gestin no pueda realizarse de manera eficiente y explicita hacia el profesional, de manera de ser una herramienta beneficiosa y no una criptografa que dificulte su trabajo.

2.5 OBSERVACIONES CLNICAS COMO INFORMACIN

Una Observacin clnica se podra definir como cualquier lectura de datos del paciente medida o no por instrumentos. La Poblacin de las mismas es considerablemente grande en cuanto a nmero de tipos. Ejemplos: Temperatura corporal, presin sangunea, electrocardiogramas, etc. Dichas observaciones poseen una diversidad y variabilidad en sus estructuras y tipos de datos (y/o subtipos) lo que demandara dentro del sistema la creacin constante de nuevos tipos , accin que crece en periocidad proporcional a la lnea de tiempo. En las figuras 5 y 6 se observa cuan complejas y dismiles pueden llegar a ser las estructuras de datos creadas a partir de las observaciones Clnicas, en el ejemplo se puede observar las estructuras de dos tipos: Presin sangunea y Temperatura corporal ambos propuesto por openEHR [4] una fundacin sin fines de lucro la cual desarrolla especificaciones y cdigo, de cdigo abierto con el propsito de buscar estndares para los sistemas en medicina.

Figura 5. Presin sangunea segn openEHR .

21

Figura 6.Temperatura corporal segn openEHR .

Ambos grficos confirman la afirmacin de que la estructura de una respectiva observacin clnica puede crecer en base a su complejidad o la exactitud buscada en la misma. Estas dos observaciones debern almacenar diferentes tipo de informacin y el sistema deber tener la capacidad de administrarlas y poder mostrarlas en su interface presentada al usuario para cualquier consulta, modificacin y sobre todo en los casos en que una consulta de un tipo de observacin requiera el mostrar por ejemplo los datos de la presin sangunea y temperatura de un mismo paciente para una consulta en particular. Este estndar propone divisiones para la agrupacin de los tipos de mediciones en subconjuntos , en la presin Data estar haciendo referencia a los datos propios de la observacin de presin sangunea; la presin diastlica o sistlica, presin arterial media y el pulso, mientras que en la temperatura corporal la divisin Data solo contiene el dato que hace referencia a la temperatura misma, por el contrario hace hincapi en State donde se destacan datos referente al estado del paciente al momento de ser efectuado el estudio como la exposicin del cuerpo o datos referentes a las condiciones del entorno en donde fue efectuada dicha observacin, ciclo menstrual, etc. Estas observaciones que son habituales, y a veces complementarias, marcan una clara diferencia tanto en la forma que toma la estructura como en los datos que se almacenan y como vara la importancia de cada una. Si a esto se suma el hecho de que existen algunas observaciones que requerirn el apoyo de, por ejemplo, datos multimedia, imgenes, sonidos, ect. Otras veces se cuenta con estudios y observaciones que sern una composicin de dos o ms. Es decir que no sern los mismos datos los que se necesitaran enviar en una ecografa, en un puntaje de apgar, presin sangunea, audiometra, etc.; de esa manera podramos nombrar una lista voluminosa de observaciones clnicas, totalmente distintas en la informacin que ofrecen, y la cual no solo se debe persistir en el sistema, sino que el mismo debe tener la capacidad de mostrarla de una manera eficiente. 22

2.6 EL

MODELO

DE

BASE

DE

DATOS

RELACIONAL

SU

PROBLEMTICA
Si respetamos el modelo actual de datos, el cual propone un modelo puramente relacional, formal y como motor de base de datos a MySQL 5, y quisiramos representar las estructuras planteadas anteriormente, deberamos representarlas mediante tablas y /o atributos en base a su anlisis, la cantidad de tablas para representar una observacin as como sus relaciones y particularidades en cuantos a tipos de datos y ocurrencias, depender de la observacin misma y la informacin que se desea guardar de ella, todo esto deber ser agregado o en un principio diseado para el unirse y por ende cambiar el diseo de base de datos preexistente es decir un conjunto de tablas relacionales diseado para el sistema original.

Figura 7. Representacin relacional de una Observacin

Figura 8. Agregacin de una nueva observacin a DB relacional

El ciclo de vida de una nueva observacin se inicia al querer integrarlas con el diseo e implementacin actual de la aplicacin, esta accin demandara un rediseo de la capa de datos y esta a su vez provocara un efecto domino causando cambios en las dems capas hasta el contacto con el usuario en la capa de presentacin as hasta culminar el ciclo en la insercin de su representacin al modelo actual. 23

Figura 9.Impacto en las capas de la Arquitectura

2.7 ANALISIS DE ESTADO

En la bsqueda de alternativas a la problemtica de observaciones clnicas deberemos analizar bsicamente puntos dbiles a mejorar o re plantear pero sobre todo aprovechar los puntos fuertes como ser las tecnologas. 2.7.1 Puntos Crticos: Capa de datos puramente relacional muy poco flexible a los cambios y complejidad est basada en la cantidad de tablas y sus relaciones existentes las cuales crecern proporcionalmente a la cantidad de observaciones que sean agradas y su representacin en el modelo relacional. Cada cambio en las estructuras provoca un rediseo total de la base de datos. 2.7.2 Impacta en todas las capas de la arquitectura actual.

Puntos Fuertes Frameworks de desarrollo utilizados basados en tecnologas XML (Extensible Markup Language).

24

CAPITULO 3
3 METODO FLEXIBLE DE PERSISTENCIA DE OBSERVACIONES CLINICAS FUNDAMENTOS TERICOS

3.1 CAMBIO DE ARQUITECTURA CAPA DE DATOS

Con el objetivo de satisfacer las problemticas de esta inicialmente seria el tomar esta porcin de la base de datos correspondiente a las observaciones clnicas, y almacenarlas en forma de metadatos dentro de un archivo de texto de manera de que su gestin sea general y flexible . Esto puede lograrse mediante el empleo de una tecnologa que permita entregar al usuario un archivo de texto, tarea que el lenguaje XML garantiza. 3.1.1 XML

XML (Extensible Markup Language) es el nuevo estndar universal para intercambio electrnico de datos. Este estndar es un metalenguaje que puede ser utilizado para describir la estructura lgica y el contenido de una gran variedad documentos, adems puede ser adaptado para satisfacer una gran cantidad de aplicaciones [5]. Al ser universal y extensible abre un rango ilimitado de usos , desde procesadores de texto, pginas web, el comercio electrnico, hasta las ms complejas soluciones de almacenamiento en bases de datos, atributo que se pretende explotar en el presente trabajo. XML permite definir lenguajes de marcado adecuados a usos determinados y de esta manera darle un requerido formato a la informacin la cual se manipula en forma de texto. Esto permite almacenar estructura de datos y relaciones en campos del tipo text o String que son atributos de una tabla.

Figura 10. Observacin como atributo TEXT

3.1.1.1 Porqu XML? Bsicamente [6]: XML es un texto marcado, con etiquetas, lo que facilita la comprensin del mismo, sin necesidad de esquemas ni aclaraciones. Los frameworks y libreras utilizados en la actualidad para el prototipo Web en la capas de control y presentacin son basados en tecnologa XML. XML es simplemente texto para estructurar datos, es decir que este texto puede ser convertido o transformado a una variable del tipo texto o String y ser manipulado en la ejecucin de un programa corriendo en java. Se trata tambin de un texto flexible, y algunos aadidos posteriores no impedirn seguir trabajando con l, y sobre todo no afectara de manera directa algn tipo de relacin dentro de la base de datos. Existen muchas herramientas para crear y leer datos XML, para buscar e incluso herramientas en las propias bases de datos, lo es una buena propuesta a la hora de un una actualizacin y escalabilidad del modelo. 3.1.1.2 Caractersticas principales de XML: Verstil: separa contenido, estructura y presentacin. Esto permite una visin personalizada de los datos. El usuario puede usar un browser para presentar los datos segn le convenga, basado en preferencias o configuracin. Extensible: se pueden definir nuevas etiquetas. Estructurado: se pueden modelar datos a cualquier nivel de complejidad 26

Validable: cada documento se puede validar frente a un DTD/Schema, o en su defecto, se puede declarar bien formado.

Abierto: independiente de plataformas, empresas, lenguajes de programacin o entornos de desarrollo.

Sencillo: fcil de aprender y de usar. Independencia del medio, pudiendo publicar contenidos en mltiples formatos. Los documentos XML son fcilmente procesables y compartibles en Internet. Permite validacin de los documentos. Permite composicin de los documentos. Puede ser un contenedor de datos. Utilizando DTD o XML Schemas se puede representar eficientemente cualquier dato de forma que puede ser ledo por

personas o aplicaciones.

XML permitir la manipulacin de la informacin como metadato en forma de texto, dentro de este archivo de texto poseer los datos correspondientes a una observacin clnica. En base a reglas para escribir un archivo XML BLood Pressure tendr la siguiente forma:

Cdigo 1 BloodPressure Empty

Como se puede observar en el cdigo mostrado arriba, se crean etiquetas con el mismo nombre que los tipos y subtipos de atributos de Blood Pressure en su modelo resumido. De 27

esta manera quedan definidos los nombres de los datos y su jerarqua pero no as el tipo de dato a utilizar, por lo tanto an no se declar ningn tipo de restriccin y los datos. El atributo Systolic por ejemplo sin restriccin podra ser un dato tipo texto un dato tipo numrico y aun as ser un documento XML bien formado, que lo que quiere decir que cumple con las reglas sintcticas del lenguaje XML.

3.1.1.3 Gramtica XML Para poder dar esta estructura deseada a nuestro datos XML posee una gramtica definida que nos permite restringir los elementos vlidos dentro de un nuevo derivado[7] de XML y puede expresarse en forma de: DTD (Document Type Definitions) : Un DTD define de la construccin del XML, permiten definir qu significa exactamente cada una de las marcas o etiquetas, disear modelos jerrquicos , describir el contenido en forma precisa y as evitar repeticiones. XSD( XML Schemas): XML Schema vence las limitaciones de los DTDs, permite definir estructuras ms complejas que en los DTDs , se puede definir tipos de datos especficos, por ejemplo no slo NMTOKEN , #PCDATA o CDATA definidos en los DTDs.XML Schema, se puede manipular de manera sencilla va VBScript o en Pginas ASP o JSP y puede establecer elementos con relaciones. 3.1.1.4 XML Schemas Podremos enumerar tres motivos por los cuales elegir XML- Schema que posee ciertas Ventajas sobre la gramtica de DTDS que son importantes para llegar a nuestro cometido : Los esquemas poseen mayor precisin en la definicin de tipos de datos mediante formatos y facetas. Los esquemas se definen como documentos XML, en un documento aparte con extensin .XSD y en los documentos XML que se basen en ese esquema, incluiremos una referencia al archivo .XSD, esto permite hacer definiciones genricas de datos que podrn usadas por varios archivos XML, dando una ventaja de reutilizacin de los mismos. Son extensibles y usan sintaxis XML al contrario de sus pares DTDs. Es decir seguiremos utilizando el mismo lenguaje sin necesidad de obtener nuevos conocimiento acerca de la forma de definir datos. 28

Figura 11. Gramtica XML

Un ejemplo de un XML Schema quedara de la siguiente manera para BloodPressure:

Cdigo 2 BloodPressure Schema

29

En este archivo xsd logramos ya definir el tipo de dato para cada atributo correspondiente a una observacin de presin sangunea:

Position: String Systolic : int

Diastolic: int

Comment: String

Method: String

No solo definimos los tipos de datos sino que tambin obligamos a que se respeta la estructura jerrquica definida en el archivo y si quisiera podra restringir la cardinalidad y las ocurrencias, por lo tanto todo estudio de la presin respeta esta estructura y la restriccin de datos, este proceso de control se llama validacin la cual no es aprobada si alguna de estas reglas se rompe. 3.1.1.5 XML BIEN FORMADO Y / O VALIDO

Como se dijo antes un XML bien formados es aquel que cumplen las reglas sintcticas de XML. Mientras que un archivo XML Validado: Es aquel que, adems de ser bien formado, sigue las reglas de una gramtica (definida en un DTD o XML Schema/ XSD). En el caso de los XSD especficamente el XML es comparado con un archivo de extensin XML .xsd en donde se encuentran definidas las estructuras de los datos esta accin es denominada Parsing y las aplicaciones que efectan la misma son llamados Parsers. 30

Figura 12. Validacin de un XML

Por lo tanto Poseeremos ambos archivos BloodPressure.xml y BloodPressure.xsd y el respectivo parser tomara el archivo .XML y lo comparara con el esquema de manera que valide los datos utilizado y la estructura de blood pressure fue respetada.

Figura 13. Parsing BloodPressure

3.1.2

TECNOLOGIAS PARA LA MANIPULACION Y DESARROLLO DE XML

El desarrollo y manipulacin de documentos en XML no es una tarea trivial, se necesitan aplicaciones que realicen las funciones de anlisis, creacin, manipulacin, entrada y salida entre otros [8]. En esta seccin se analizara los diferentes parsers disponibles y sobre todo su tecnologa para poder ser utilizada en Java. 3.1.2.1 PARSERS 31

3.1.2.1.1 DOM (Document Object Model) El API est estandarizada por elW3C (http://www.w3c.org) Disponible para varios lenguajes Tiene soporte para generacin de XML El documento XML completo es cargado en memoria y El API incluye mtodos para aadir , borrar o modicar nodos y extremidades A diferencia de SAX, DOM permite a los desarrolladores navegar el documento en cualquier direccin El poder adicional que ofrece DOM se traduce en un mayor costo en trminos de uso de memoria

DOM genera un rbol jerrquico en memoria del documento o informacin en XML, basndose del documento anterior cada elemento <Data>, <Protocol>, etc. es considerado un nodo dentro del rbol. Este rbol jerrquico de informacin en memoria permite que a travs del "parser" ( Xerces [9] o algn otro) sea manipulada la informacin, las ventajas seran las siguientes:

Puede ser agregado un nodo (Informacin) en cualquier punto del rbol. Puede ser eliminada informacin de un nodo en cualquier punto del rbol. Lo anterior se ejecuta sin incurrir en las penalidades o limitaciones de manipular un archivo de alguna otra manera.

Debido a que DOM es solo una especificacin existen diversos "parsers" DOM.

Un detalle notorio de cualquier "Parser" es que la mayora estn escritos en Java , esta no es ninguna coincidencia ya que Java es uno de los lenguajes que permite mayor portabilidad entre Sistemas Operativos. Ahora bien, a pesar de esta portabilidad en Java, DOM es solo una especificacin y por ende existen diversas implementaciones. El utilizar un "Parser" implica aprender a utilizar sus clases o funciones o API ("Application Programming Interface"), como el API de Xerces del proyecto, sin embargo, ciertas clases o funciones difieren un poco en los diversos "Parsers" , por eso se recomienda que los programas o aplicaciones que requieran de las funcionalidades de un "Parser" sean diseadas alrededor de JAXP ("Java API for XML Processing") .

3.1.2.1.2 SAX("Simple API for XML") 32

SAX procesa ("parse") el documento o informacin en XML de una manera muy diferente a DOM, SAX procesa la informacin por eventos. A diferencia de DOM que genera un rbol jerrquico en memoria , SAX procesa efectivamente la informacin en XML conforme esta sea presentada (evento por evento), manipulando cada elemento a un determinado tiempo , sin incurrir en uso excesivo de memoria. Por lo tanto puede notar las siguientes caractersticas:

SAX es un "parser" ideal para manipular archivos de gran tamao, ya que no es necesario generar un rbol en memoria como en DOM.

Es ms rpido y sencillo que utilizar DOM La sencillez antes mencionada tiene su precio, debido a que SAX funciona por eventos no es posible manipular informacin una vez procesada, en DOM no existe esta limitacin ya que se genera el rbol jerrquico en memoria y es posible regresar a modificar nodos.

La especificacin ms reciente de SAX es 2.0, y al igual que DOM 2.0 esta se incluye en casi todos los "Parsers" disponibles en el mercado.

Casi todos los "Parsers" incluyen tanto una implementacin para DOM como para SAX y dependiendo de su situacin tiene la flexibilidad de utilizar DOM o SAX. Para que sea posible el migrar o adaptar un programa o aplicacin a diferentes parsers como "Xerces",Oracle , Si utiliza Java, surgi JAXP. 3.1.2.2 JAXP Eventualmente es posible podremos descubrir que su sistema de informacin empiece a utilizar uno u otro parsers se comporte mejor que otro o quizs descubramos que

determinado "Parser" utiliza menos memoria y es ms veloz en ejecucin nuestra aplicacin lo que hace delicado el proceso de eleccin del mismo ya que se deber hacer una ponderacin entre los pro y contra de cada uno en base al entorno de desarrollo que poseeremos y las incompatibilidades que pudieran surgir del mismo. De cualquier manera siempre es conveniente insular una aplicacin de cualquier incompatibilidad, en este caso podremos lograrlo mediante JAXP el cual que se logra esta independencia de "parsers" XML . La principal razn detrs de JAXP es precisamente la interoperabilidad "Write once run everywhere" (Escrbalo una vez ejectelo en todos lados) de Java, al existir diversos "Parsers" escritos en Java lo anterior resultara falso y por esta razn Sun ideo JAXP. JAXP no es "Parser" sino un grupo de clases integradas a todo "Parser", esto garantiza que un programa escrito hacia un "Parser" con soporte JAXP puede ser migrado a otro sin ningn problema. 33

Otra inclusin en JAXP es TraX que tambin es un grupo de clases que permiten interoperabilidad Java entre los diversos XSL Engines , esto permite una migracin entre estas herramientas utilizadas en XSL; vale mencionar que TraX es parte JAXP. 3.1.2.3 Java + XML = JDOM

A pesar de existir diversos "Parsers" para ambientes Java las metodologas SAX y DOM no fueron diseadas con Java en mente, con la intencin de proporcionar una metodologa para procesar XML ms acorde con el mundo Java surgi JDOM , la cual une lo mejor de los 2 ; SAX y DOM y est hecha exclusivamente para java lo que hace que un programador en java pueda sin mucho esfuerzo comprender su sintaxis [10].

3.2 CAMBIO DE ARQUITECTURA CAPA DE INTEGRACION

Al poseer datos en formato XML en nuestra base de datos una nueva capa deber agregarse a la arquitectura actual la cual se encargara de manipulacin de esta informacin, haciendo transparente el traslado de informacin desde la capa de datos a la capa de negocios. En esta capa se utilizara el API JDOM el cual se encargara de la transparencia en cuanto a la manipulacin de datos.

Figura 14. Cambio en Arq. Nueva Capa integracin

3.2.1

JDOM

JDOM es una biblioteca open source o de formato abierto para la manipulacin optimizada de datos XML con java. A diferencia de los dems Api para la manipulacin de XML , JDOM es un api puro de java basado en rbol para crear, parsear, manipular y serializar documentos en XML. Posea lo mejor de Sax y DOM y el rbol est compuesto por clases y disponible todo el tiempo [11]. JDOM fue escrito para y con java, por lo tanto utiliza las convenciones de java y posee sus propias clases y mtodos para la manipulacin de XML. Es posible trabajar con cualquier parser, en este trabajo se utilizar Xercers, un parsers con licencia apache al igual que JDOM y que es considerado el parser por defecto adems de 34

poseer compatibilidad con XML Schema que es condicin necesaria para validar nuestros archivos XML.

Figura 15. JDOM Pack Structure

JDOM surgi porque DOM y SAX no eran suficientes. SAX no permite modificaciones al documento, acceso aleatorio o capacidades de salida (output) y requiere a menudo construir una mquina de estado. DOM no es muy familiar para el programador en Java, pues est definido en IDL un comn denominador a travs de lenguajes ms bajo. As como DOM, JDOM representa un documento XML como un rbol compuesto por

elementos, atributos, comentarios, instrucciones de proceso, nodos de texto, secciones CDATA y as sucesivamente. El rbol completo est disponible todo el tiempo. A diferencia de SAX, JDOM puede acceder cualquier parte del rbol en cualquier momento. En contraste a DOM, todos los diferentes tipos de nodos del rbol son representados por clases concretas en lugar de interfaces. Adems, no hay una interfaz o clase genrica Node (DOM) de la que extiendan o implementen todas las diferentes clases de nodo , esto hace que las operaciones para navegar el rbol y buscar no sean ms incmodas de lo que son en DOM. JDOM usa constantemente las convenciones de codificacin de Java y la biblioteca de clase, todas las clases primarias de JDOM tienen equals(), toString(), y mtodos hashCode(), todas ellas implementan las interfaces Cloneable y Serializable. Almacenan los hijos de un Element o de un objeto Document en una java.util.List. Se hace especial nfasis en este punto ya que a un programador de Java le es mucho ms fcil y cmodo trabajar con un API que le es familiar. JDOM no incluye por s mismo un parser. En vez de eso depende de un parser de SAX con un manejador de contenido comn para parsear documentos y construir modelos JDOM a partir 35

de estos. JDOM viene con Xerces 1.4.4, pero puede trabajar de igual manera con cualquier parser compatible con SAX2 incluyendo Crimson, AElfred (el parser de Oracle XML para Java), Piccolo, Xerces-2. Cualquiera de estos puede leer un documento XML y ponerlo en JDOM y puede tambin convertir objetos Documento de DOM en objetos de Documento de JDOM. Es as mismo til para hacer un pipe de la salida de programas DOM existentes en la entrada de un programa en JDOM. Sin embargo, si se est trabajando con un flujo de datos de XML que se lee de un disco o de la red, es preferible usar SAX para producir el rbol JDOM y as evitar la sobrecarga de construir el rbol en memoria dos veces en dos representaciones . Los datos para construir el rbol en JDOM pueden provenir de una fuente que no sea XML, como una base de datos o literales en un programa de java. JDOM chequea todos los datos para ver que se construya un documento XML bien formado. Una vez que el documento se ha cargado en memoria, JDOM puede modificar el documento y el rbol generado es

completamente de lectura-escritura a diferencia de DOM donde si pueden haber secciones de slo lectura. Finalmente una vez que se ha terminado de trabajar con el documento en memoria, JDOM permite serializar el documento de nuevo al disco o a un flujo de bytes. JDOM provee numerosas opciones para especificar la codificacin, los caracteres de fin de lnea, espaciado, y otros detalles de la serializacin. Otra alternativa, es producir una secuencia de eventos SAX o un documento DOM de salida en lugar de convertir el documento en un flujo de datos. Es decir Jdom nos permitir no solo manipular nuestros archivos sino que tambin permite serializar los mismos de nuevo al disco o a un flujo de bytes. Provee numerosas opciones para especificar la codificacin, los caracteres de fin de lnea, espaciado, y otros detalles en cuanto a la serializacin. Tambin puede producir una secuencia de eventos SAX o u n documento DOM. Creo que JDOM rompe muchas barreras entre Java y XML y lo hace ver ms natural Simon St. Laurent, Autor de XML Elements of Style. 3.2.2 METHOD CORE

MethodCore ser el nombre de las libreras principales y funciones que poseern toda la lgica de la nueva capa de integracin es donde usando el lenguaje java y las capacidades de Jdom se administrar toda la informacin en forma de texto mediantes funciones de parseo y serializacin, method core sea una caja negra que poseer como entra o salida un String XML o un Objeto que represente cualquier observacin.

36

37

CAPITULO 4
4 CONCEPTOS INVOLUCRADOS
4.1 PATTERNS - PATRONES DE DISEO
El uso de patrones ayuda a obtener un software de calidad (reutilizacin y extensibilidad).Un catlogo de patrones es un conjunto de recetas de diseo. Aunque se pueden clasificar, cada patrn es independiente del resto. Los patrones son soluciones tcnicas ya que dada una determinada situacin, los patrones indican cmo resolverla mediante un D.O.O. (Diseo Orientado a Objetos) Existen patrones especficos para un lenguaje determinado, y otros de carcter ms general. Los patrones proceden de la experiencia. Han demostrado su utilidad para resolver problemas que aparecen frecuentemente en el D.O.O. Son soluciones simples que Indican cmo resolver un problema particular utilizando un pequeo nmero de clases relacionadas de forma determinada. No indican cmo disear un sistema completo, sino slo aspectos puntuales del mismo. Facilitan la reutilizacin de las clases y del propio diseo y favorecen la reutilizacin de clases ya existentes y la programacin de clases reutilizables. La propia estructura del patrn es reutilizada cada vez que se aplica [12].

4.1.1

DAO- DTO

4.2 PATRONES GOF

4.2.1 ABSTRACT FACTORY 4.2.1.1 DESCRIPCION VENTAJAS Proporcionar una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas. 4.2.1.2 Aplicabilidad Cuando un sistema deba ser independiente de la creacin, composicin y representacin de sus productos. Cuando un sistema deba ser configurado productos. Cuando un conjunto de objetos relacionados se disea para ser usado conjuntamente. con una de las mltiples familias de

Cuando se desea proporcionar una biblioteca de productos de los que slo se quiere conocer su interfaz

Asla las clases concretas. Permite intercambiar fcilmente familias de Productos. Proporciona consistencia entre productos.

4.2.1.3 DESVENTAJAS Dificulta la incorporacin de nuevas clases de productos.

4.2.2

FACTORY METHOD

4.2.2.1 DESCRIPCION Consiste en utilizar una clase constructora (al estilo del Abstract Factory) abstracta con unos cuantos mtodos definidos y otro(s) abstracto(s), dedicado a la construccin de objetos de un subtipo de un tipo determinado. Es una simplificacin del Abstract Factory, en la que la clase abstracta tiene mtodos concretos que usan algunos de los abstractos; segn usemos una u otra hija de esta clase abstracta, tendremos uno u otro comportamiento. 4.2.2.2 VENTAJAS Se unen jerarquas de clase paralelas proporcionando relaciones para la creacin de subclase y la extensin. 4.2.2.3 DESVENTAJAS No se saben de antemano todas las clases que deben ser creadas aplazando la creacin de objetos a las clases con el contexto. 4.2.3 PROTOTYPE

4.2.3.1 DESCRIPCION VENTAJAS Tiene como finalidad crear nuevos objetos duplicndolos, clonando una instancia creada previamente .Este patrn aparece en ciertos escenarios donde es preciso abstraer la lgica que decide que tipos de objetos utilizar una aplicacin, de la lgica que luego usarn esos objetos en su ejecucin. Los motivos de esta separacin pueden ser variados, por ejemplo, puede ser que la aplicacin deba basarse en alguna configuracin o parmetro en tiempo de ejecucin para decidir el tipo de objetos que se debe crear Cuando en un sistema se usen este patrn en muchos objetos de negocio, conviene tener un prototype manager para preguntarle si tal o cual objeto es prototpico. 4.2.3.2 DESVENTAJAS Necesite una familia de objetos de producto relacionados de ser usado juntos y si necesita la ejecucin de esta coaccin, necesita un sistema para apoyar mltiples familias de interfaz de necesidad de clases para crear objetos sin saber sus tipos 39

4.3 PATRONES DE ARQUITECTURA

4.3.1 MVC

El Modelo Vista Controlador es un patrn para el desarrollo del software que se basa en separar los datos (por un lado), la interfaz del usuario (por otro) y la lgica interna (por un ltimo lado). Es mayormente usado en aplicaciones web, dnde la vista es la pgina HTML, el modelo es el Sistema de Gestin de Base de Datos y la lgica interna, y el controlador es el responsable de recibir los eventos y darles solucin. A continuacin vamos a desgranar ms cada elemento: Modelo: Es la representacin de la informacin en el sistema. Trabaja junto a la vista

para mostrar la informacin al usuario y es accedido por el controlador para aadir, eliminar, consultar o actualizar datos. Vista: Es la presenta al modelo en un formato adecuado para que el usuario pueda

interactuar con l, casi siempre es la interfaz de usuario. Controlador: Es el elemento ms abstracto. Recibe, trata y responde los eventos

enviados por el usuario o por la propia aplicacin. Interactuar tanto con el modelo como con la vista.

4.3.2

Arquitectura en n capas

El Patrn de arquitectura por capas es una de las tcnicas ms comunes que los arquitectos de software utilizan para dividir sistemas de software complicados. Al pensar en un sistema en trminos de capas, se imaginan los principales subsistemas de software ubicados de la misma forma que las capas de un pastel, donde cada capa descansa sobre la inferior. En este esquema la capa ms alta utiliza varios servicios definidos por la inferior, pero la ltima es inconsciente de la superior. Adems, normalmente cada capa oculta las capas inferiores de las siguientes superiores a esta. Los beneficios de trabajar un sistema en capas son: Se puede entender una capa como un todo, sin considerar las otras. Las capas se pueden sustituir con implementaciones alternativas de los mismos servicios bsicos Se minimizan dependencias entre capas. Las capas posibilitan la estandarizacin de servicios Luego de tener una capa construida, puede ser utilizada por muchos servicios de mayor nivel. 40

La imagen que se muestra a continuacin presenta el esquema de una arquitectura siguiendo este patrn:

A continuacin se describen las tres capas principales de un patrn de arquitectura por capas: 1. Capa de Presentacin: Referente a la interaccin entre el usuario y el software. Puede ser tan simple como un men basado en lneas de comando o tan complejo como una aplicacin basada en formas. Su principal responsabilidad es mostrar informacin al usuario, interpretar los comandos de este y realizar algunas validaciones simples de los datos ingresados. 2. Capa de Reglas de Negocio (Empresarial): Tambin denominada Lgica de Dominio, esta capa contiene la funcionalidad que implementa la aplicacin. Involucra clculos basados en la informacin dada por el usuario y datos almacenados y validaciones. Controla la ejecucin de la capa de acceso a datos y servicios externos. Se puede disear la lgica de la capa de negocios para uso directo por parte de componentes de presentacin o su encapsulamiento como servicio y llamada a travs de una interfaz de servicios que coordina la conversacin con los clientes del servicio o invoca cualquier flujo o componente de negocio. 3. Capa de Datos: Esta capa contiene la lgica de comunicacin con otros sistemas que llevan a cabo tareas por la aplicacin. Estos pueden ser monitores transaccionales, otras aplicaciones, sistemas de mensajeras, etc. Para el caso de aplicaciones empresariales, generalmente est representado por una base de datos, que es responsable por el almacenamiento persistente de informacin. Esta capa debe abstraer completamente a las capas superiores (negocio) del dialecto utilizado para comunicarse con los repositorios de datos (PL/SQL, Transact-SQL, etc.).

Figura 16. Arquitectura en n capas

41

4.4 FRAMEWORKS J2EE

4.4.1 JSF JAVA SERVER FACE Es un framework con tecnologa para aplicaciones Java Web basadas en el patrn MVC donde las vistas conocen la accin que se va a invocar en su peticin. Que simplifica el desarrollo de interfaces de usuario en aplicaciones Java EE [13]. JSF usa Java Server Pages (JSP) como la tecnologa que permite hacer el despliegue de las pginas. JSF incluye: Un conjunto de APIs para representar componentes de una interfaz de usuario y administrar su estado, manejar eventos, validar entrada, definir un esquema de navegacin de las pginas y dar soporte para internacionalizacin y accesibilidad. Un conjunto por defecto de componentes para la interfaz de usuario. Dos libreras de etiquetas personalizadas para JavaServer Pages que permiten expresar una interfaz JavaServer Faces dentro de una pgina JSP. Un modelo de eventos en el lado del servidor. Administracin de estados. Beans administrados.

Desde el punto de vista tcnico podemos destacar los siguientes: JSF forma parte del estndar J2EE, mientras que otras tecnologas para creacin de vistas de las aplicaciones no lo forman, como por ejemplo Struts. JSF dispone de varias implementaciones diferentes, incluyendo un conjunto de etiquetas y APIs estndar que forman el ncleo del framework. Entre estas implementaciones cabe destacar la implementacin de referencia de Sun Microsystems, actualmente desarrollada como un proyecto open source, y la implementacin del proyecto Apache, MyFaces, dotada de un conjunto de extensiones que la hacen muy interesante para el desarrollo de aplicaciones corporativas. El desarrollo de JSF est realmente empezando. Las nuevas versiones del framework recogen la funcionalidad de versiones anteriores siendo su compatibilidad muy alta, de manera que el mantenimiento de aplicaciones no se ve penalizado por el cambio de versiones.

42

4.4.2

ICEFACES

ICEfaces es un Framework Ajax que permite desarrollar Aplicaciones RIA de una manera fcil y rpida, utilizando el lenguaje Java. ste est basado en una serie de estndares que permiten continuar trabajando con la clsica forma de desarrollo con Java. Permite al programador incluir una serie de Ajax-tags en sus JSP o xhtml de tal manera que el cdigo Ajax es generado por el propio framework automticamente.

ICEFaces asla completamente al desarrollador de AJAX. No hacen falta etiquetas especiales: se ponen los controles en la pantalla e ICEFaces se encarga de enviar slo la informacin necesaria entre cliente y servidor. Es decir, ya no se envan los formularios a la antigua usanza, en un POST de HTTP, sino que slo se envan los cambios que ha hecho el usuario del cliente al servidor, y los cambios en la pantalla del servidor al cliente [14].

De esa manera, se puede trabajar con herramientas existentes como NetBeans, Eclipse; y Servidores de Aplicaciones como Sun GlassFish, Apache Tomcat, IBM WebSphere, JBoss, entre otros .

43

CAPITULO 5
5 METODO FLEXIBLE APLICACIN PASO A PASO
Este mtodo propone diferentes pasos que permiten el crear diversas estructuras de datos e insertarlas dentro de un modelo relacional preexistente, no perder la coherencia de datos y la coexistencia de ambas estructuras. Permitir que la nueva estructura creada sea flexible en su creacin y modificacin impactando lo menos posible en la estructura de datos original y en las diferentes capas. En otras palabras la informacin correspondiente a una observacin debe poder persistir en un campo de tipo String o texto. Esto se podra representar en un ejemplo como una tabla Observaciones cuyos atributos podran ser los siguientes:

Figura 17 Tabla Observaciones

Id Observacin: Sera el nmero identificador de cada observacin. Id Tipo: Sera el identificador que dir qu tipo de observacin es la persistida. Detalle: Es un atributo del tipo String en formato XML que deber poseer todos los datos de la observacin propiamente dicha. En esta tabla que sera perteneciente al modelo total de aplicacin y tendr almacenada toda la informacin correspondiente a toda la observacin cargada en la aplicacin. Los estados por los que pasara una observacin en su viaje desde un usuario a la base de datos y viceversa serian:

INFORMACION USUARIO

OBSERVACION CLINICA :

Datos de paciente + detalle de la observacin.

Detalle: Conversin de la informacin a Texto .(XML)

Guardar en la base de datos.

Figura 18 Estados de una observacin usuario a DB

INFORMACION EN BASE DE DATOS

PARSEO

Conversin de String en datos de Observacion

Objeto DTO Obtener un objeto que posea la infromacion ensus atributos.

Mostrar al Usuario

Figura 19 - Estados de una observacin DB a Usuario

Todos estos estados y los procesos que demanden dentro de la nueva capa de integracin debern como se plante en un principio, ser transparente frente a la capa de negocios para que no sea necesario conocer el tipo de base datos con el que interacciona si no simplemente la informacin en la forma que la recibe hasta ahora.

Figura 20 Capa de Datos + Integracin

5.1 Paso 1 Diseo de la estructura de los datos en formato de texto CAPA DE DATOS
Plantearemos paso a paso como se debera imprentar el mtodo a partir de un ejemplo aumentando su complejidad de menor a mayor y justificando los pasos que se toman en cada caso . Si deseramos por ejemplo tomar la presin sangunea de un paciente cualquiera y los datos que necesitamos medir fueran los siguientes 45

Posicin del paciente al tomar la mediciones Valor de Presin Sistlica Valor de Presin Diastlica El mtodo con el que se haya tomado la misma Un comentario u observacin sobre la medicin

Datos que seran una versin reducida de la estructura propuesta por OpenEHR.

Figura 21 BloodPressure Structure OPENEHR

Con el conocimiento de los dato necesarios a obtener deberemos definir las plantillas o modelos en forma de archivos de texto que sern los encargados de definir la estructura de estas medidas mediante el leguaje de marcas XML, lo que permitir en etapas posteriores del mtodo el poder manipular la informacin en forma de un String o de texto, el mismo nos permitir mediante su semntica definir particularidades como su estructura y sus tipo de datos. Para el mismo ejemplo propuesto anteriormente: presin sangunea una definicin de sus datos seria de la siguiente forma:

46

Cdigo 3 - BloodPressure XML Template

El primer archivo cuya extensin ser .XML, archivo poseer la jerarqua y organizacin de los datos propios de la observacin de presin Sangunea. Lo primero que se observa que si bien la distribucin y jerarqua estn definidas no as los tipos de datos pertenecientes a cada atributo. Para esto se deber definir un nuevo archivo de texto escrito igualmente en

lenguaje XML pero con extensin .xsd, ( Un archivo XML con gramtica de XML-Schemas). Este tipo de XML nos permite no solo definir los tipos de cada dato y relaciones entre ellos si es que las mismas existieran, as como cardinalidades y ocurrencias de los mismos. Que para el mismo ejemplo podra 47 ser el siguiente:

Cdigo 4 BloodPressure.xsd

5.2 Paso 2 Creacin de una clase DTO

Al observar la estructura de los archivos antes vistos deducimos cual ser la informacin que viajar del usuario a la base de datos y viceversa. Es por eso que deberemos crear una nueva clase que posea atributos con sus equivalentes en datos java por cada observacin nueva y segn su tipo para poder transportar dicha informacin, para esto una buena opcin sera el utilizar el Patrn DTO. Para nuestro ejemplo deberamos crear la clase ObservationDTO.java de la siguiente manera. (Asumimos que cada atributo tiene su mtodo set() y get() y una funcin pblica vaca) 48

Cdigo 5 ObservationDTO.Java

De esta manera las instancias de esta clase o mejor dicho los objetos del tipo ObservacionDTO me servirn para poder llevar a la vista la informacin de la observacin o en todo caso obtener datos ingresados por el usuario para luego ser convertido en un String XML, en otra palabras como una unidad de transporte de la informacin de las observaciones con las que se trabajara.

5.3 Paso 3 Parseo y Serializacin Capa de Integracin

Bsicamente un parseo es un anlisis o una conversin. En el caso propuesto ser la conversin de a un objeto de tipo String recuperado desde la base de datos, a un objeto del tipo observationDTO , el cual nos servir para mostrarlo al usuario final, modificar , luego guardar , etc.

En otro caso se obtendr observationDTO otorgado por el usuario a travs de una interface visual, para luego convertirlo en un objeto de tipo objeto de tipo String. Objeto que luego ser persistido en la base de datos como tal, siendo simplemente un atributo de tabla, especficamente corresponder al atributo Detalle de la tabla ejemplo. Este proceso es llamado serializacin Para eso se podr definir una clase a la cual podramos llamar Analizer.java que Implementara 2 mtodos un mtodo parser() que recibir el String y devolver un objeto del tipo ObservationDTO y un mtodo serialize() que recibir el objeto y devolver un String XML y a estos dos mtodos se agregara un mtodo validate que ser el encargado de validar la gramtica de los XML Schema o archivos xsd. 49

Diagrama 1 Analizer Class

5.3.1

METODO PARSE()

EL mtodo parse() tendr la siguiente firma public ObservationDTO parse(String XML) este recibir el String XML del tipo de observacin requerido. El mismo realizara los siguientes pasos:

En primer lugar se validar el String que posee la informacin para asegurarnos su buena formacin en XML y la validacin de con las reglas del Schema correspondiente.

Crear un objeto del tipo Document de JDOM a partir del cual podremos obtener su raz y recorrer el rbol de elementos y/o su contenido.

Crear un objeto del tipo ObservacionDTO el cual llevara en su instancia los datos de la observacin.

Obtendr utilizando el API JDOM los elementos del XML y se los cargara en el objeto del tipo observationDTO.

Retornar el ObservationDTO generado.

Para el ejemplo se particularizar de la siguiente manera : La nueva clase seria BloodPressureAnalizer.java manera: y su mtodo parser() se implementara de la siguiente

50

Cdigo 6 Iparseable.Java

5.3.2

METODO SERIALIZE() o Serializacin public String serialize(IParseable

EL mtodo serialize() tendr la siguiente firma

dtoObservation, String xmlTemplate), este recibir el objeto DTO del tipo de observacin correspondiente para transformarlo en String, el cual ser persistido en la base de dato. Un detalle de este mtodo es que el mismo recibir como parmetro una plantilla (template) como referencia, o sea un objeto XML String vaco correspondiente al tipo de observacin que se quiere transformar a String. Este mtodo seguir los siguientes pasos: En primer lugar se validara la plantilla que posee la informacin para asegurarnos su buena formacin en XML y su validacin. Luego crearemos un objeto del tipo Document de JDOM a partir del cual podremos recorrer el rbol de elementos y su contenido. Obtendremos utilizando el API JDOM los elementos del XML y se llenara los campos con los datos del objeto recibido por parmetro. Retornaremos el String XML a persistir.

Particularizado para nuestro ejemplo seria: 51

Cdigo 7 Mtodo Serialice ()

Existen consideraciones a tener en cuenta en cuanto a el analyzer.java las funciones no hacen el control de con qu tipo de observacin se est trabajando ya que se deber crear un objeto analizer para cada tipo de observacin.

5.4 Paso 4 Persistencia en la base de datos - Capa de Integracin

Una vez que ya tenemos las clase y mtodos que nos otorgan la capacidad de navegar un XML obtener sus datos como el transformar los datos ingresado en un String es decir traducir nuestra informacin y obtener o el texto para el atributo detalle en la tabla observacin, ahora deberemos crear la respectivas clases para poder persistir en la base de datos la informacin en la tabla observaciones. Por ende la tabla base de datos tendr su propia clase para persistir los datos y un mtodo setDetail (String cadena) y mtodos como crate, update o delete que sern los encargados de la administracin de la persistencia no solo del atributo detail sino de todos los atributos de la tabla propiamente dicha. Para el uso de la misma se podra crea una clase

ObservationDAO encargada de los siguientes mtodos. Guardar una observacin Modificar una observacin Eliminar una observacin Obtener una observacin a partir de un String. 52

5.4.1

Guardar en la Base de Datos

Particularizado para nuestro ejemplo debemos primero crear un objeto del tipo ObservationDTO en el cual se cargara el tipo de observacin y por supuesto el detalle resultante de llamar a la funcin parser. Nota: Se podr crear una factora que ser la encargada de entregar la plantilla vaca en base al tipo de observacin a parsear

Cdigo 8 AddObservatinDB ()

5.4.2

Modificar una observacin en la Base de datos

En este mtodo debemos obtener los datos de la observacin guardada y luego sobrescribir los datos a modificar que se encuentren en el objeto del tipo ObservationDTO, para nuestro ejemplo el mtodo seria:

53

Cdigo 9 updateObservationDB()

5.4.3

Eliminar y obtener Observacin

A su vez los mtodos eliminar y obtener tendra esta forma.

Cdigo 10 deleteObservationDB()

54

Cdigo 11 getObservation()

5.5 METODO GENERALIZADO

En base a lo anterior observamos que para la creacin de cualquier observacin deberemos seguir los siguientes pasos: 1. Diseo de los datos, es decir la generacin de 2 archivos de texto que respetaran la gramtica de XML Schemas: a. .XML: Donde se encuentran los datos propiamente dichos de una observacin. b. .xsd: Define la estructura de los datos como los tipos de los mismos y/o relaciones entre los tipos de datos. 2. Creacin de una clase DTO que refleje los datos a obtener y persistir en la base de datos o mostrar al usuario 3. Creacin de mtodos de parseo y serializacin que se encargaran del anlisis de los archivos XML. 4. Creacin de una clase que implemente mtodos de persistencia en la base de datos por cada observacin El cdigo mostrado en el ejemplo esta particularizado para una sola observacin, no estara visto desde una perspectiva de desarrollo en grupo o una escalabilidad considerable. En un caso real, la aplicacin no solo manipulara varias observaciones si no que las mismas cambiaran en la lnea del tiempo y se agregaran muchas otras y por ende estos pasos deberan generalizarse de manera de abstraerse de ciertas complicaciones y generar una serie de pasos sencillos y casi mecnicos a la hora de agregar una observacin. Para llegar a nuestro objetivo deberemos explotar conceptos muy fuertes de la Diseo y la programacin orientada a objetos tales como herencia, encapsulamiento y Atraccin. 5.5.1 Herencia

La herencia es un mecanismo que permite la definicin de una clase a partir de la definicin de otra ya existente. La herencia permite compartir automticamente mtodos y datos entre clases, subclases y objetos. 55

La herencia est fuertemente ligada a la reutilizacin del cdigo en la OOP. Esto es, el cdigo de cualquiera de las clases puede ser utilizado sin ms que crear una clase derivada de ella, o bien una subclase. La herencia presenta los siguientes beneficios: Las subclases proveen conductas especializadas sobre la base de elementos comunes provistos por la superclase. A travs del uso de herencia, los programadores pueden reutilizar el cdigo de la superclase muchas veces. Los programadores pueden implementar superclases llamadas clases abstractas que definen conductas "genricas". Las superclases abstractas definen, y pueden implementar parcialmente, la conducta pero gran parte de la clase no est definida ni implementada. Otros programadores concluirn esos detalles con subclases especializadas. Hay dos tipos de herencia: Herencia Simple y Herencia Mltiple. La primera indica que se pueden definir nuevas clases solamente a partir de una clase inicial mientras que la segunda indica que se pueden definir nuevas clases a partir de dos o ms clases iniciales. Java slo permite herencia simple, sin embargo la herencia mltiple es implementada a travs de la Interfaces las cuales servirn en nuestro caso para poder crear contratos que respetaran todas las clases que implemente una misma interface. 5.5.2 Encapsulamiento

El encapsulamiento es bsicamente el empaquetamiento de las variables de un objeto con la proteccin de sus mtodos. Tpicamente, el encapsulamiento es utilizado para esconder detalles de la puesta en prctica, los mismos pueden cambiar en cualquier tiempo sin afectar otras partes del programa, esta particularidad es muy importante a la hora de un desarrollo en grupo y para las posibles nuevas funciones. El encapsulamiento de variables y mtodos en un componente de software ordenado es, todava, una simple idea poderosa que provee dos principales beneficios a los desarrolladores de software: Modularidad, esto es, el cdigo fuente de un objeto puede ser escrito, as como darle mantenimiento, independientemente del cdigo fuente de otros objetos pudiendo ser planificado por diversos programadores sin que estos dependan del funcionamientos de los otros mdulos existentes y que el mismo no afecte al desarrollo final. As mismo, un objeto puede ser transferido alrededor del sistema sin alterar su estado y conducta. Ocultamiento de la informacin, es decir, un objeto tiene una "interfaz publica" que otros objetos pueden utilizar para comunicarse con l. Pero el objeto puede mantener informacin y mtodos privados que pueden ser cambiados en cualquier tiempo sin afectar a los otros objetos que dependan de ello. 56

Los objetos proveen el beneficio de la modularidad y el ocultamiento de la informacin. Las clases proveen el beneficio de la reutilizacin. Los programadores de software utilizan la misma clase, y por lo tanto el mismo cdigo, una y otra vez para crear muchos objetos.

5.6 OBSERVACIONES CLNICAS

Para poder observar el comportamiento propondremos un nuevo tipo de observacin Body Temperture o temperatura corporal, el esquema propuesto por OpenEHR sera el siguiente:

Figura 22 BodyTemperature OPENEHR

Una vez ms tomaremos una versin reducida del mismo y los datos a obtener serian: BodyExposure: exposicin del cuerpo Temperature: temperatura Device: dispositivo con el que fue medido.

Figura 23 - BodyTemperature version reducida.

La versin de XML y XSD seria 57

Cdigo 12 BodyTemperature.xml

Xsd:

Cdigo 13 BodyTemperature.xsd

Podemos notar en las definiciones como es que una observacin posee distintos tipos de datos pero al a vez un criterio de agrupacin de los mismos como son los grupos DATA, PROTOCOL, etc. 58

Una vez mas no solo se definen los tipos de datos sino que tambin obliga a que se respete la estructura jerrquica definida en el archivo y si se quisiera se podra restringir la cardinalidad como el nivel de anidamiento requerido, por lo tanto toda observacin clnica de la presin deber respetar esta estructura y la restriccin de datos para ser un archivo XML validado. Al poseer ya dos o ms tipos se necesita el buscar formas de generalizar los pasos antes propuesto para poder de alguna forma controlar la poblacin de observaciones dentro del sistema y que su creacin no llego a lo complejo.

5.7 APLICACIN DE INTERFACES

Las interfaces describen el comportamiento que poseen muchas clases distintas, en otras palabras una interfaz es una coleccin de operaciones que especifican el servicio de una determinada clase o componente. Una interfaz describe el comportamiento visible externamente de ese elemento, puede mostrar el comportamiento completo o slo una parte del mismo. Una interfaz describe un conjunto de especificaciones de operaciones (o sea, su signatura) pero nunca su implementacin. Esta caracterstica del modelado Orientado a Objetos nos permitir generalizar e independizarnos de la implementacin en s de cada una de las clases, las interfaces utilizas para este caso seran las siguientes. El uso de interfaces proporciona las siguientes ventajas: Organizar la programacin (IAJU). Obligar a que ciertas clases utilicen los mismos mtodos (nombres y parmetros). Establecer relaciones entre clases que no estn relacionadas. La principal diferencia entre interface y abstract es que un interface proporciona un mecanismo de encapsulacin de los protocolos de los mtodos sin forzar a utilizar la herencia.

5.7.1

INTERFACES Iparseable

La interface Iparseable ser una interface vaca la cual ser implementada por todas las clases que represente a los DTO de cada observacin es decir de alguna manera su nico objetivo ser agrupar en un mismo tipo de dato a todos los objetos que debern ser parseados o serializados, o dicho de otra manera crear el grupo de los objetos a ser serializados o parseados. 59

Diagrama 2 Interface IParseable

Un ejemplo de cdigo seria el siguiente:

Cdigo 14 BodyTemperature DTO

5.7.2

INTERFACES IAnalizable

La interfaces IAnalizable ser la encargada de crear un contrato que debern respetar todas las clases encargadas del anlisis de los datos en formato XML. La creacin de esta interface me facilitar la independencia en cuanto a la tecnologa con la que se implementaran de los mtodos pudiendo cambiar el API o parsers utilizados actualmente por algn otro en otro momento sea ms conveniente y no necesariamente JDOM el cual es nuestra eleccin actual. Observaremos que la creacin de esta interface y la generalizacin de sus mtodos se hacen posibles solo gracias a la creacin de la interface IParseable la cual es usada por IAnalizable. 60

Cdigo 15 Implements IAnalizable

IAnalizable:

Diagrama 3 Interface IAnalizable

61

Cdigo 16 Contrato de IAnalizable

5.8 IMPLEMENTACION DEL PATRN FACTORY

Factory proporciona una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas. Nos proporcionara las siguientes ventajas: Asla las clases concretas. Permite intercambiar fcilmente en los grupos de datos. Proporciona consistencia entre tipos de Observaciones.

Este patrn proveer un mtodo para la obtencin de cada objeto de su familia as como la creacin de la instancia concreta a utilizar. El cliente trabajar directamente sobre esta interfaz, que ser implementada por las diferentes clases concretas. 5.8.1 FACTORY AnalizerFactory

Al existir diferentes tipos de observaciones la aplicacin deber poseer una forma por el cual identificar que clase analizer utilizar en base al tipo de observacin con la que se est trabajando, para eso se utilizara el patrn Factory el cual creara una instancia del Analizer correspondiente en base al tipo que se solicite.

62

Diagrama 4 Analizer Factory

EL cdigo de implementacin seria (AnalyzeFactory.java):

Cdigo 17 - AnalyzeFactory.java

5.8.2

FACTORY TemplateFactory

Al generar un archivo XML y un XSD para cada observacin deberemos tener un formato inicial o un formato base o template de referencia en cual otorgara la estructura a los datos a persistir, de la misma manera se necesitara algn modo en que la aplicacin sepa que template o plantilla a utilizar en base al tipo de observacin. En base al patrn Factory se 63

creara una clase que genere una instancia de esquema en base al tipo de observacin. Diagrama de objeto:

Diagrama 5 Template Factory

Cdigo 18 - Template Factory

64

5.9 IMPLEMENTACION DEL PATRN DAO

Los Objetos del tipo DAO manejan la conexin con la fuente de datos para obtener y almacenar datos, es decir lo referente a la persistencia. El uso de este patrn ofrecer varios beneficios para la persistencia de datos: Servir para separar el acceso a datos de la lgica de negocio en esta capa. Encapsular la fuente de datos. As conseguiremos la transparencia a las antiguas capas de datos y su sinergia con la nueva capa de integracin. Oculta la API con la que se accede a los datos. En este caso utilizaremos JPA hibernate pero podr usarse cualquier otro y esto no cambiara la lgica del desarrollo. Por lo tanto, al realizar una operacin, se abrir la conexin a la base, se ejecutara el comando, si es una operacin de lectura, se volcara el contenido hacia una estructura de datos y se cerrara la conexin. 5.9.1 INTERFACES IObservationDAO

Esta interface ser la encargada del contrato de los mtodos de persistencia en la base de datos, en este caso su nico objetivo ser independizarme de la tecnologa con la que se persiste. La implementacin de la persistencia cambiara un poco en cuanto a las formas de sus mtodos ms que nada ya que ahora solo con enviar el Id del tipo de observacin y gracias a que se implementa factoras para las creacin de los Analizers y de los templates se tendr una sola clase DAO la cual poseer mtodos que con solo enviar el id del tipo de observacin con la que se desea persistir identificara la misma para utilizar el analizar y el template que le corresponda.

Diagrama 6 - ObservationDAO

El cdigo de IObservationDTO seria: 65

Cdigo 19 - IObservationDTO

La implementacin de esta interface seria la siguiente:

Cdigo 20 - ObservationDAO

66

67

Cdigo 21 ObservationDAOImp

68

5.10 DIAGRAMA DE CLASES

Diagrama 7 Diagrama de clases MethodCore

5.11 CONCLUSIONES DE LA GENERALIZACIN

La solucin que se plantea es el poder crear estas estructuras diversas en formato de texto sin perder, ni perjudicar el modelo real y /o la coherencia con el mismo. En Base a estas ideas se desea aprovechar la ventaja de XML, un leguaje de marcas muy poderoso para manipular texto y poder darle un formato a la informacin. Al poder dar formato a mi informacin en forma de texto tengo la posibilidad de poder almacenar el mismo con tan solo una variable del tipo texto dentro de una tabla. Se suma la ventaja que poseemos el poder contralar el cambio de las estructura de una manera flexible sin alterar por completo el modelo relacional y manteniendo la coherencia del mismo. Con este nuevo enfoque que para la creacin de cualquier observacin deberemos seguir los siguientes pasos: 1. Diseo de los datos, es decir la generacin de 2 archivos de texto que respetaran la gramtica de XML Schemas, dichos archivos sern guardado 69

en la base de dato como atributos tipo TEXT o BLOB, ya sea en forma de template o con el detalle de observaciones. 2. Creacin de una clase DTO que refleje los datos a obtener y persistir en la base de dato o mostrar al usuario, la misma deber implementar Interface IParseable. 3. Creacin de una clase que implemente la interface IAnalizable por ende los mtodos de parseo y serializacin que se encargaran del anlisis y conversin de los archivos XML con el detalle de cada observacin. 4. Agregar condiciones correspondientes en clases Factory, simplemente se agregara una o 2 lneas de cdigo segn corresponda a cada una de las clases factoras para el tipo de observacin especifica.

Lo Que deberemos notar es que la creacin de una clase DAO solo se efectuara una vez ya que ella solo depender del id del nuevo tipo de Observacin en la tabla observaciones. 5. Creacin de mtodos de persistencia en la base de datos a partir de la implementacin de la interface IObservationDAO. De esta manera cada desarrollador solo deber seguir los paso o trabajar en cualquier de ellos indistintamente hasta completar todos.

70

ESCALABILIDAD
6 ESCALABILIDAD
Como ya se dijo anteriormente , la capa de control esta implementada con Java Server Faces (JSF) particularmente mediante el framework ICE Faces 1.8 que en la actualidad esta siendo migrado a la versin 3. Estas herramientas aportan benficos tales como el poder utilizar tecnologas como AJAX [15] acrnimo de Asynchronous JavaScript And XML (JavaScript asncrono y XML), permite crear aplicaciones ms interactivas y rpidas. Y las hojas de estilo CSS (Cascading Style Sheets)[16]. Entregando un diseo dinmico. Y como resultado despegar la presentacin del contenido. Sin embargo la creacin de las mencionadas estructura en las capas de datos afectaran las vistas existentes, teniendo que desarrollar las modificaciones de las actuales vistas por nuevas en las cuales se consideren los nuevos tipos de observaciones a la hora de, por ejemplo, ver los datos de presin correspondiente a un paciente en especial y mucho mayor, aun, en caso que se deba comparar ms de una observacin en la misma vista. En base a este problema, si se pudiera usar plantillas para las vistas de cada observacin, se podra, tambin, hacer una anidacin de las mismas y la reutilizacin de cdigo de por medio; es decir crear una vista y poder utilizarla una y otra vez, combinndola con sus pares creando vistas complejas a partir de vistas independientes. Esto disminuira el problema de la mantencin del sistema, como as tambin, la generacin de las nuevas vistas, simplificando los procesos de esta capa en general. As Facelet[17], un framework para plantillas (templates), no solo cumple con lo antes expuesto si no que est centrado en la tecnologa JSF y viene ya incluido en la ltima versin de JSF 2, versin que forma parte de la nueva migracin de la aplicacin. El mismo es un complemento perfecto de icefaces ya que incorpora nuevas funciones fciles de desarrollar, siendo un perfecto componente para trabajar con las tecnologas utilizadas en nuestro sistema. Facelet tambin utiliza la creacin de un rbol de UIcomponent (User Interface component) y soporta las deseadas plantillas reutilizables. De esta manera este framework entrega la posibilidad de crear una vista por cada nueva estructura proporcionado la capacidad de reutilizar cada facelet, poder anidarlos y agruparlos en una misma vista, segn la necesidad.

Esto dara la posibilidad de crear nuevas APIs que generen automticamente las vistas tomando como punto de partida los archivos xml que definen la estructura de observaciones clnicas.

Basado en los ejemplos anteriores estas cualidades de facelet llevaran a tener una correspondencia de uno a uno con la definicin de la estructura, en este caso con BloodPressure.xsd; dando la ventaja de agregar solo una plantilla nueva (facelets template) por cada observacin agregada quedando casi intacta la interaccin de las antiguas vistas haciendo que sea sencilla tanto su creacin como su mantenimiento y/o modificacin. De esta manera gracias a los cambios en el modo de persistencia se mejorara el desarrollo de y la implementacin de las vistas o de las presentaciones de estas observaciones.

Figura 24 -Se puede crear una relacin directa entre las vistas y las estructura y combinar las vistas segn sea necesario.

72

CAPITULO 7
7 CONCLUSIONES
Se utilizaron alternativas basadas en software libre, cuyo conjunto brinda flexibilidad a la hora de administrar y visualizar la informacin referente a observaciones clnicas. Se logr independizar las estructuras de datos de las reglas del modelo relacional tradicional. Se reduzco el impacto que produce la administracin y sobre todo la creacin de nuevas observaciones clnicas, en flexibilidad del lenguaje XML. En base al nuevo diseo se cre un conjunto de libreras que pueden ser usadas por la aplicacin actual una vez se produzcan los cambios propuesto en la arquitectura, este ncleo de libreras puede ser alterado en base a una serie de pasos reproducibles por cualquier desarrollador Java cuya curva de aprendizaje muy corta. Gracias a los cambios propuestos en la arquitectura se facilitar el manejo de la informacin dentro de la aplicacin, haciendo hincapi en la reutilizacin de cdigo y fcil mantenimiento del mismo. las capas del sistema inicial, explotando la potencialidad y

Se propuso solucionar problemas de forma innovadora empleando tecnologas simples para atender las problemticas an no del todo resueltas de forma tradicional.

CAPITULO 8
8 BIBLIOGRAFIA
[1] Pablo F. Solarz , Viviana I Rotger y Luis Medina Ruiz, "Prototipo Web para Telemedicina", SABI 2009. [2] Ministerio de Sanidad y Consumo de Madrid , "IN SALUD PLAN DE TELEMEDICINA", 2000. [3] Pedro Jos Blanco Andrs,"BASES DE DATOS MULTIMEDIA", ETIS, 2005. [4] "http://www.openehr.org", Documentacin online, Sitio de la fundacin openEHR. [5] Grigoris Antoniou and Frank van Harmelen, "A Semantic Web Primer - Second edition" , The MIT Press Cambridge, Massachusetts, London, England, 2008. [6] Daniel Martnez vila, "Tendencias y usos de XML en Biblioteconoma y Documentacin",Master en Investigacin en Documentacin 2008. [7] Introduccin al Lenjuaje XML - Mariano Posadas - Grupo Eidos - 2000 [8] Ricard Lou Torrijos, "El API JAXP", http://www.programacion.com, 2010. [9] Apache Jakarta Xerces (www.apache.org), Documentacin. [10] Jason Hunter (Co-Creator JDOM Project), "JDOM Makes XML Easy",JavaOne, Sun`s Worldwide Java Developer Conference, 2002. [11] http://www.jdom.org, Documentacin online, Sitio sobre el proyecto JDOM. [12] Deepak Alur, John Crupi, Dan Malks, "Core J2EE Patterns: Best Practices and Design Strategies", Second Edition,Prentice Hall PTR, 2003. [13] "http://java.sun.com/javaee/javaserverfaces/", Documentacin online, Sitio de Sun Microsystems sobre la tecnologa Java Server Faces. [14] "http://www.icefaces.org/",Documentacin online, Sitio de ICE soft Technologies Inc. Sobre tecnologa ICEFaces- / ICEfaces 1.8: Next Generation Enterprise Web Development Rainer Eschen [15] Jesse James Garrett ,"Ajax: A New Approach to Web Applications", 2005. [16] "http://www.w3.org/TR/REC-xml/", Documentacin online, Sitio Recomendaciones W3C. [17] Bruno Aranda and Zubin Wadia, "Facelets Essentials Guide to JavaServer Faces View Definition Framework", First Press, 2008.

75