Embed Size (px)
DESCRIPTION
Presentación PREZI : http://prezi.com/8r_oawxcyuby/metodo-flexible-de-persistencia-tesis-de-grado/?auth_key=662ddd553cf21b81d91c8c260da218b0d408c1ac
Citation preview
UNIVERSIDAD NACIONAL DE TUCUMÁN FACULTAD
DE CIENCIAS EXACTAS Y TECNOLOGÍA
DEPARTAMENTO DE ELECTRICIDAD,
ELECTRÓNICA Y COMPUTACIÓN
Trabajo de Graduación - Informe Final
MÉTODO FLEXIBLE DE PERSISTENCIA DE
OBSERVACIONES CLÍNICAS
Autor : Darwin Rodrigo Zottola Pareja
CX1015599
Ingeniería en Computación – Plan 2004
Tutor: Ing. Solarz, Pablo Federico
Instituto de Bio Electrónica
Co – Tutor : Ing. Steifensand, Jorge
Tucumán – Diciembre 2012
2
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.-
3
Agradecimientos
Agradezco en primer lugar a Dios y la virgen por darme la oportunidad de llegar hasta acá,
agradezco por su colaboración en este trabajo a profesores, en especial al ingeniero Pablo
Solarz, al IBE (Instituto de Bio Electrónica) 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.
4
Contenido Agradecimientos ....................................................................................................................... 3
Contenido ................................................................................................................................. 4
Índice de imágenes ................................................................................................................... 7
Índice de Diagramas .................................................................................................................. 8
Índice de Código Fuente ............................................................................................................ 9
Resumen ................................................................................................................................. 10
Glosario .................................................................................................................................. 11
1 INTRODUCCION ............................................................................................................... 12
1.1 PROBLEMÁTICA - MOTIVACIONES ............................................................................ 12
1.2 OBJETIVOS ............................................................................................................... 14
1.2.1 Objetivos Principal ........................................................................................... 14
1.2.2 Objetivos generales ......................................................................................... 14
2 APLICACIÓN WEB PARA TELEMEDICINA CHASQUI ........................................................... 17
2.1 ARQUITECTURA ....................................................................................................... 17
2.2 TECNOLOGIAS ACTUALES ........................................................................................ 18
2.3 MODELO FUNCIONAL .............................................................................................. 18
2.4 PROBLEMÁTICA ACTUAL .......................................................................................... 20
2.5 OBSERVACIONES CLÍNICAS COMO INFORMACIÓN ................................................... 21
2.6 EL MODELO DE BASE DE DATOS RELACIONAL Y SU PROBLEMÁTICA ........................ 23
2.7 ANALISIS DE ESTADO ............................................................................................... 24
2.7.1 Puntos Críticos: ................................................................................................ 24
2.7.2 Puntos Fuertes ................................................................................................. 24
3 METODO FLEXIBLE DE PERSISTENCIA DE OBSERVACIONES CLINICAS – FUNDAMENTOS TEÓRICOS ............................................................................................................................... 25
3.1 CAMBIO DE ARQUITECTURA – CAPA DE DATOS ....................................................... 25
3.1.1 XML ................................................................................................................. 25
3.1.2 TECNOLOGIAS PARA LA MANIPULACION Y DESARROLLO DE XML ..................... 31
3.2 CAMBIO DE ARQUITECTURA – CAPA DE INTEGRACION ............................................ 34
3.2.1 JDOM ............................................................................................................... 34
3.2.2 METHOD CORE................................................................................................. 36
4 CONCEPTOS INVOLUCRADOS .......................................................................................... 38
4.1 PATTERNS - PATRONES DE DISEŃO .......................................................................... 38
4.1.1 DAO- DTO ........................................................................................................ 38
5
4.2 PATRONES GOF........................................................................................................ 38
4.2.1 ABSTRACT FACTORY ......................................................................................... 38
4.2.2 FACTORY METHOD ........................................................................................... 39
4.2.3 PROTOTYPE ...................................................................................................... 39
4.3 PATRONES DE ARQUITECTURA ................................................................................ 40
4.3.1 MVC ................................................................................................................. 40
4.3.2 Arquitectura en n capas ................................................................................... 40
4.4 FRAMEWORKS J2EE ................................................................................................. 42
4.4.1 JSF – JAVA SERVER FACE................................................................................... 42
4.4.2 ICEFACES .......................................................................................................... 43
5 METODO FLEXIBLE APLICACIÓN PASO A PASO ................................................................ 44
5.1 Paso 1 Diseño de la estructura de los datos en formato de texto -CAPA DE DATOS .. 45
5.2 Paso 2 Creación de una clase DTO ........................................................................... 48
5.3 Paso 3 Parseo y Serialización – Capa de Integración ................................................. 49
5.3.1 METODO PARSE() ............................................................................................. 50
5.3.2 METODO SERIALIZE() o Serialización ................................................................ 51
5.4 Paso 4 Persistencia en la base de datos - Capa de Integración ................................ 52
5.4.1 Guardar en la Base de Datos ............................................................................ 53
5.4.2 Modificar una observación en la Base de datos ................................................ 53
5.4.3 Eliminar y obtener Observación ....................................................................... 54
5.5 METODO GENERALIZADO ........................................................................................ 55
5.5.1 Herencia .......................................................................................................... 55
5.5.2 Encapsulamiento ............................................................................................. 56
5.6 OBSERVACIONES CLÍNICAS ....................................................................................... 57
5.7 APLICACIÓN DE INTERFACES .................................................................................... 59
5.7.1 INTERFACES – Iparseable.................................................................................. 59
5.7.2 INTERFACES – IAnalizable ................................................................................. 60
5.8 IMPLEMENTACION DEL PATRÓN FACTORY ............................................................... 62
5.8.1 FACTORY – AnalizerFactory .............................................................................. 62
5.8.2 FACTORY – TemplateFactory ............................................................................ 63
5.9 IMPLEMENTACION DEL PATRÓN DAO ...................................................................... 65
5.9.1 INTERFACES – IObservationDAO ....................................................................... 65
5.10 DIAGRAMA DE CLASES ............................................................................................. 69
5.11 CONCLUSIONES DE LA GENERALIZACIÓN ................................................................ 69
6
6 ESCALABILIDAD ............................................................................................................... 71
7 CONCLUSIONES ............................................................................................................... 73
8 BIBLIOGRAFIA.................................................................................................................. 74
7
Índice de imágenes
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. Presión sanguínea según openEHR . ______________________________________________ 21
Figura 6.Temperatura corporal según openEHR . ___________________________________________ 22
Figura 7. Representación relacional de una Observación _____________________________________ 23
Figura 8. Agregación de una nueva observación a DB relacional _______________________________ 23
Figura 9.Impacto en las capas de la Arquitectura ___________________________________________ 24
Figura 10. Observación como atributo TEXT _______________________________________________ 26
Figura 11. Gramática XML _____________________________________________________________ 29
Figura 12. Validación 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 observación usuario a DB _______________________________________ 45
Figura 19 - – Estados de una observación DB a Usuario ______________________________________ 45
Figura 20 – Capa de Datos + Integración__________________________________________________ 45
Figura 21 – BloodPressure Structure OPENEHR _____________________________________________ 46
Figura 22 –BodyTemperature OPENEHR __________________________________________________ 57
Figura 23 - BodyTemperature version reducida.____________________________________________ 57
Figura 24 -Se puede crear una relación directa entre las vistas y las estructura y combinar las vistas
según sea necesario. _________________________________________________________________ 72
8
Í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
9
Índice de Código Fuente
Código 1 – BloodPressure Empty ........................................................................................................... 27
Código 2 – BloodPressure Schema ......................................................................................................... 29
Código 3 - BloodPressure XML Template ............................................................................................... 47
Código 4 – BloodPressure.xsd................................................................................................................ 48
Código 5 – ObservationDTO.Java .......................................................................................................... 49
Código 6 – Iparseable.Java .................................................................................................................... 51
Código 7 – Metodo Serealize() .............................................................................................................. 52
Código 8 – AddObservatinDB() .............................................................................................................. 53
Código 9 – updateObservationDB() ....................................................................................................... 54
Código 10 – deleteObservationDB()....................................................................................................... 54
Código 11 – getObservation() ............................................................................................................... 55
Código 12 – BodyTemperature.xml ....................................................................................................... 58
Código 13 – BodyTemperature.xsd ........................................................................................................ 58
Código 14 – BodyTemperature DTO ...................................................................................................... 60
Código 15 – Implements IAnalizable ...................................................................................................... 61
Código 16 – Contrato de IAnalizable...................................................................................................... 62
Código 17 - AnalyzeFactory.java ........................................................................................................... 63
Código 18 - Template Factory .............................................................................................................. 64
Código 19 - IObservationDTO ................................................................................................................ 66
Código 20 - ObservationDAO ................................................................................................................ 66
Código 21 – ObservationDAOImp .......................................................................................................... 68
Resumen El siguiente trabajo propone método de persistencia de información, flexible y dinámico, y su
aplicación 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 Tucumán. La actual arquitectura de software, que contiene un modelo puramente
relacional en su capa de persistencia, presenta en particular el inconveniente de que la gestión
y administración de la información referente a observaciones clínicas, que se caracterizan por
una gran variabilidad en su estructura y tipo de datos, implica un nuevo diseño e
implementación del esquema de datos cada vez que se ingresa un nuevo tipo de observación,
impactando en el resto de las capas de la arquitectura ante lo cual dicho método propone
formas alternativas al manejo actual de la información dentro del sistema representando
observaciones clínicas con estructuras en lenguaje XML, y que sirven además de base a la capa
de presentación. De esta manera, nuevos tipos de observaciones clínicas tienen que ver con
agregar el modelo correspondiente en XML y su presentación, impactando mínimamente 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 –informática medica – aplicaciones web – XML – Parsers – Java
– J2EE – Icefaces – POO
11
Glosario
OBSERVACIONES MÉDICAS:
SERIALIZACIÓN: La serialización consiste en un proceso de codificación de un objeto en un
medio de almacenamiento (como puede ser un archivo, o un buffer de memoria) con el fin de
transmitirlo a través de una conexión en red como una serie de bytes o en un formato
humanamente más legible como XML o JSON, entre otros.
CAPITULO 1
INTRODUCCION 1 INTRODUCCION
EL proyecto de telemedicina en Tucumán [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 Tucumán (SIPROSA) y se encuentran dispersos en
el interior de la provincia. En dichos centros existe un aprovechamiento deficiente de los
recursos físicos y humanos, así como la mala difusión de los servicios que se prestan y la falta
de médicos especialistas, ocasionando la generación de un importante número de
derivaciones innecesarias hacia los centros de mayor complejidad.
La Organización Mundial de la Salud (OMS), define a la Telemedicina como: “El suministro
de servicios de atención sanitaria, en los que la distancia constituye un factor crítico, por
profesionales que apelan a las tecnologías de la información y de la comunicación con objeto
de intercambiar datos para hacer diagnósticos, preconizar tratamientos y prevenir
enfermedades y heridas, así como para la formación permanente de los profesionales de
atención de salud y en actividades de investigación y evaluación, 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 Tucumán” desarrolla de una red telemédica
multimedia que permita la comunicación entre centros asistenciales rurales, hospitales
centrales y agentes de salud en general.
En él se desarrolla software que permite básicamente virtualizar las interconsultas médicas
haciendo uso de herramientas multimedia para permitir usar todos los elementos de
diagnóstico: imágenes (Rx, Ecografías), videos (ecocardiogramas), Audio (Auscultaciones desde
estetoscopios electrónicos), texto (Resultados de análisis, informes, etc.). Además de la
comunicación entre los agentes mediante audio, video, chat, tanto on-line como off-line.
1.1 PROBLEMÁTICA - MOTIVACIONES
Para desarrollar las prestaciones de una aplicación web que otorgue servicios para crear
una comunicación multimedia en aplicaciones para telemedicina, hace que cualquier
13
desarrollo de este tipo requiera retos en cuanto a la representación digital de la información
médica ya sea en diseños, implementación y sobre todo en la organización de los datos y su
persistencia. Es entendible que para una comunicación de este tipo se requiere una gran
cantidad de datos que deberá ser recibida por el usuario y manipulada por el mismo a través
de la aplicación.
El modelo de datos relacional planteado para el prototipo web de telemedicina tiene resueltos
muchos de los aspectos sobre la gestión de datos de información análoga a la procesada por
los sistemas de gestión en general, pero aun siendo tan fuerte este diseño posee puntos
débiles en cuanto a la representación de la información específicamente de las “Observaciones
Clínicas”.
La necesidad surge del problema que tienen los modelos actuales de gestión de base de datos
para satisfacer necesidades en sistemas médicos debido a la diversidad de los tipos de
Observaciones médicas y con ello no solo diversidad de tipo de datos si no lo mas importante
la diversidad en las estructuras que son necesarias formar para cado uno de estas
Observaciones [3].
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 podríamos sumar el hecho que su crecimiento en cuanto a cantidad de tipos y la
variación de sus estructura basadas en actualizaciones o nuevas investigaciones son
significativamente variables en la línea de tiempo, lo que demuestra que no se trabaja con
estructuras estables y estáticas, - Haciendo referencia al modelo relacional completo - sino
todo lo contrario. Esto hace que su administración se vuelva compleja y sobre todo que la
agregación o eliminación de alguna de ellas significa un impacto en el sistema, ya que se
deberá hacer un rediseño de la base de datos y por ende esto producirá un efecto domino
afectando cada una de las capas de la arquitectura de la aplicación.
Un ejemplo seria el listar observaciones como presión sanguínea, temperatura corporal , una
ecografía, un electrocardiograma, etc.; cualquier observación de este tipo puede llegar a
poseer datos tan sencillos como el saber cuál sería el valor de presión alta y cual el valor de la
baja, o datos complejos como analizar los puntos de una imagen de alta calidad para dar un
diagnósticos dermatológico y tal vez el procesar la información de una electrocardiograma, y
14
esto en base a la precisión 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 específico se desee a
este estudio puede crecer a un tamaño considerable. La misma que deberá luego ser agregada
a nuestra base de datos. Existirán otras observaciones que poseerán igual, menor o mayor
tamaño en su estructura, y sobre todo que serán de estructura diversas y complemente
diferentes.
Esto implicaría no solo modificar el diseño de la base de datos, si no hacer las debidas
modificaciones en las diferentes capas, la de negocios, la de aplicación etc. de esta manera
este sería el procedimiento cada vez que se agregue un nuevo tipo de observación.
1.2 OBJETIVOS 1.2.1 Objetivos Principal
En primer el objetivo de este proyecto se basa en Implementar una metodología de
Persistencia de información (sobre observaciones clínicas), que sea flexible, dinámica y hacer
factible su futura aplicación 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 administración (flexibilidad a la hora de crear, modificar y borrar una
observación clínica).
Reducir el impacto en cada capa de la Arquitectura del Sistema.
Mejorar el mantenimiento y la reutilización del código.
Simplificar el trato de la información en las distintas capas hasta su presentación al
usuario.
En otras palabras afectar mínimamente las capas de la arquitectura por cada inclusión de las
nuevas estructura, buscando soluciones para cada una de ellas o para todas en conjunto.
Crear una metodología en la cual nos independicemos del modelo relacional sin perder sus
beneficios pudiendo mantener la coherencia de los datos y su combinación y con el sistema
inicial actuando ambos como uno solo.
Permitir el crear diversas observaciones clínicas 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 creación y modificación,
impactando mínimamente en la estructura de datos original.
15
Dicha metodología 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 capacitación. Es decir la administración de dicha información y que su desarrollo
pueda ser repetido y reproducido, con el mínimo costo y una curva de aprendizaje corta.
CAPITULO 2
APLICACIÓN WEB PARA
TELEMEDICINA “CHASQUI”
2 APLICACIÓN WEB PARA TELEMEDICINA CHASQUI Agregando a lo antes expuesto se podría agregar que el objetivo de la aplicación web para
telemedicina es favorecer la calidad de las prestaciones de la salud pública 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
periféricas de las ciudades como de zonas rurales. En este capítulo se analizara a fondo su
arquitectura y problemáticas.
2.1 ARQUITECTURA La Figura 1 muestra un esquema de la arquitectura actual de la aplicación 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 clínicas, agentes de salud
colaboradores, etc. (Implementada con MySQL). La capa de negocios donde residen los
programas que se ejecutan, es también donde se reciben las peticiones del usuario y se envían
las respuestas tras el proceso. Estas reglas de negocios creadas en esta capa fueron
18
implementadas con lenguaje Java 1.6. La capa que se encuentra entre la capa de aplicación 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 presentación que es la que se
comunica con el usuario final. Hoy en día estas tecnologías están siendo migradas a nuevas
versiones y actualizaciones de los respectivos frameworks y Apis con los que se trabaja.
2.2 TECNOLOGIAS ACTUALES
Actualmente las tecnologías utilizadas por la aplicación 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
móviles incluyendo el intercambio de texto, voz, imágenes, videos, etc. que dan soporte a los
métodos complementarios de diagnóstico.
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, imágenes, etc. a la web.
Los actores típicos del sistema son: Paciente y Agente Sanitario por el lado del Hospital rural,
que requieren al sistema el servicio de asistencia entregando información sobre la dolencia del
19
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 información, para dar solución al pedido original.
Las características más importantes de la aplicación se las puede resumir a partir de 2
escenarios de uso:
1) Ingresar un archivo multimedia a la base de datos de la aplicación para que quede
disponible en “conversaciones” posteriores. Esta tarea se realiza:
a. Ingresando datos del paciente relevantes (no necesariamente identificarlo)
b. Señalando en la interfaz la ubicación 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) Colaboración entre los actores compartiendo archivos. Esta tarea se realiza:
a. Uno de los usuarios incorpora en la conversación uno o más 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.
20
b. La aplicación se encarga de replicar esta tarea en todos los usuarios
colaboradores, permitiéndoles compartir la misma documentación 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 PROBLEMÁTICA ACTUAL La información 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 información es de naturaleza muy diversa. Puede existir
información en las historias clínicas, en los diagnósticos o en los informes médicos que pueden
complicar en extremo la gestión de estas informaciones o dicha información en su totalidad
transformarse ilegible, de difícil acceso, ambigua o exigua, lo que dificulta la creación de
soluciones en cuento a su representación como datos digitales dentro de alguna aplicación.
Esto no siendo un problema general a nivel de cualquier sistema dentro del entorno médico.
Son diversos lo orígenes de la información médica y en particular de las observaciones clínicas;
pueden provenir del paciente, del profesional, dispositivos o de cada servicio, lo que supone la
existencia de un gran número de formatos distintos que complican su manejo, y su
persistencia en base de datos que pueden tornarse compleja sin la debida representación y
administración.
Esto pone en evidencia la diversidad de información que se debe administrar dentro de un
sistema que contenga observaciones clínicas en forma de datos, otorgándole la
obligatoriedad de un cambio y adaptación continua.
Hablando sobre las historias clínicas y los diagnósticos apoyados en su contenido, un punto
de quiebre es la existencia de una diversidad abundante y extensa en cuanto a las
21
observaciones clínicas, la información pertenecientes a las mismas y sobre todo en las
estructuras usadas para representar las mismas; su constante adhesiones y /o
transformaciones, hacer su gestión no pueda realizarse de manera eficiente y explicita hacia el
profesional, de manera de ser una herramienta beneficiosa y no una criptografía que dificulte
su trabajo.
2.5 OBSERVACIONES CLÍNICAS COMO INFORMACIÓN
Una Observación clínica se podría definir como cualquier lectura de datos del paciente medida
o no por instrumentos. La Población de las mismas es considerablemente grande en cuanto a
número de tipos. Ejemplos: Temperatura corporal, presión sanguínea, 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 creación constante de nuevos tipos ,
acción que crece en periocidad proporcional a la línea de tiempo.
En las figuras 5 y 6 se observa cuan complejas y disímiles pueden llegar a ser las estructuras de
datos creadas a partir de las observaciones Clínicas, en el ejemplo se puede observar las
estructuras de dos tipos: Presión sanguínea y Temperatura corporal ambos propuesto por
openEHR [4] una fundación sin fines de lucro la cual desarrolla especificaciones y código, de
código abierto con el propósito de buscar estándares para los sistemas en medicina.
Figura 5. Presión sanguínea según openEHR .
22
Figura 6.Temperatura corporal según openEHR .
Ambos gráficos confirman la afirmación de que la estructura de una respectiva observación
clínica puede crecer en base a su complejidad o la exactitud buscada en la misma. Estas dos
observaciones deberán almacenar diferentes tipo de información y el sistema deberá tener la
capacidad de administrarlas y poder mostrarlas en su interface presentada al usuario para
cualquier consulta, modificación y sobre todo en los casos en que una consulta de un tipo de
observación requiera el mostrar por ejemplo los datos de la presión sanguínea y temperatura
de un mismo paciente para una consulta en particular. Este estándar propone divisiones para
la agrupación de los tipos de mediciones en subconjuntos , en la presión “Data” estará
haciendo referencia a los datos propios de la observación de presión sanguínea; la presión
diastólica o sistólica, presión arterial media y el pulso, mientras que en la temperatura corporal
la división “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 exposición del cuerpo o datos referentes a las
condiciones del entorno en donde fue efectuada dicha observación, 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 varía la
importancia de cada una. Si a esto se suma el hecho de que existen algunas observaciones que
requerirán el apoyo de, por ejemplo, datos multimedia, imágenes, sonidos, ect. Otras veces se
cuenta con estudios y observaciones que serán una composición de dos o más. Es decir que no
serán los mismos datos los que se necesitaran enviar en una ecografía, en un puntaje de apgar,
presión sanguínea, audiometría, etc.; de esa manera podríamos nombrar una lista voluminosa
de observaciones clínicas, totalmente distintas en la información 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.
23
2.6 EL MODELO DE BASE DE DATOS RELACIONAL Y SU
PROBLEMÁTICA
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 quisiéramos representar las estructuras
planteadas anteriormente, deberíamos representarlas mediante tablas y /o atributos en base
a su análisis, la cantidad de tablas para representar una observación así como sus relaciones y
particularidades en cuantos a tipos de datos y ocurrencias, dependerá de la observación
misma y la información que se desea guardar de ella, todo esto deberá ser agregado o en un
principio diseñado para el unirse y por ende cambiar el diseño de base de datos preexistente
es decir un conjunto de tablas relacionales diseñado para el sistema original.
Figura 8. Agregación de una nueva observación a DB relacional
El ciclo de vida de una nueva observación se inicia al querer integrarlas con el diseño e
implementación actual de la aplicación, esta acción demandaría un rediseño de la capa de
datos y esta a su vez provocaría un efecto domino causando cambios en las demás capas
hasta el contacto con el usuario en la capa de presentación así hasta culminar el ciclo en la
inserción de su representación al modelo actual.
Figura 7. Representación relacional de una Observación
24
Figura 9.Impacto en las capas de la Arquitectura
2.7 ANALISIS DE ESTADO
En la búsqueda de alternativas a la problemática de observaciones clínicas deberemos analizar
básicamente puntos débiles a mejorar o re plantear pero sobre todo aprovechar los puntos
fuertes como ser las tecnologías.
2.7.1 Puntos Críticos:
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 crecerán proporcionalmente a la cantidad de
observaciones que sean agradas y su representación en el modelo
relacional.
Cada cambio en las estructuras provoca un rediseño total de la base
de datos.
Impacta en todas las capas de la arquitectura actual.
2.7.2 Puntos Fuertes
Frameworks de desarrollo utilizados basados en tecnologías XML
(Extensible Markup Language).
CAPITULO 3
3 METODO FLEXIBLE DE PERSISTENCIA DE OBSERVACIONES
CLINICAS – FUNDAMENTOS TEÓRICOS
3.1 CAMBIO DE ARQUITECTURA – CAPA DE DATOS
Con el objetivo de satisfacer las problemáticas de esta inicialmente seria el tomar esta porción
de la base de datos correspondiente a las observaciones clínicas, y almacenarlas en forma de
metadatos dentro de un archivo de texto de manera de que su gestión sea general y flexible .
Esto puede lograrse mediante el empleo de una tecnología 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 estándar universal para intercambio
electrónico de datos. Este estándar es un metalenguaje que puede ser utilizado para describir
la estructura lógica y el contenido de una gran variedad documentos, además 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,
páginas web, el comercio electrónico, hasta las más 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 información 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.
26
Figura 10. Observación como atributo TEXT
3.1.1.1 Porqué XML?
Básicamente [6]:
XML es un texto marcado, con etiquetas, lo que facilita la comprensión del mismo, sin
necesidad de esquemas ni aclaraciones.
Los frameworks y librerías utilizados en la actualidad para el prototipo Web en la capas
de control y presentación son basados en tecnología 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
ejecución de un programa corriendo en java.
Se trata también de un texto flexible, y algunos añadidos posteriores no impedirán
seguir trabajando con él, y sobre todo no afectaría de manera directa algún tipo de
relación 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 actualización y escalabilidad del modelo.
3.1.1.2 Características principales de XML:
Versátil: separa contenido, estructura y presentación. Esto permite una visión
personalizada de los datos. El usuario puede usar un browser para presentar los datos
según le convenga, basado en preferencias o configuración.
Extensible: se pueden definir nuevas etiquetas.
Estructurado: se pueden modelar datos a cualquier nivel de complejidad
27
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 programación o
entornos de desarrollo.
Sencillo: fácil de aprender y de usar.
Independencia del medio, pudiendo publicar contenidos en múltiples formatos.
Los documentos XML son fácilmente procesables y compartibles en Internet.
Permite validación de los documentos.
Permite composición 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 leído por
personas o aplicaciones.
XML permitirá la manipulación de la información como metadato en forma de texto, dentro
de este archivo de texto poseerá los datos correspondientes a una observación clínica.
En base a reglas para escribir un archivo XML BLood Pressure tendrá la siguiente forma:
Código 1 – BloodPressure Empty
Como se puede observar en el código mostrado arriba, se crean etiquetas con el mismo
nombre que los tipos y subtipos de atributos de Blood Pressure en su modelo resumido. De
28
esta manera quedan definidos los nombres de los datos y su jerarquía pero no así el tipo de
dato a utilizar, por lo tanto aún no se declaró ningún tipo de restricción y los datos.
El atributo “Systolic” por ejemplo sin restricción podría ser un dato tipo texto un dato tipo
numérico y aun así ser un documento XML bien formado, que lo que quiere decir que cumple
con las reglas sintácticas del lenguaje XML.
3.1.1.3 Gramática XML
Para poder dar esta estructura deseada a nuestro datos XML posee una gramática definida
que nos permite restringir los elementos válidos dentro de un nuevo derivado[7] de XML y
puede expresarse en forma de:
• DTD (Document Type Definitions) : Un DTD define de la construcción del XML,
permiten definir qué significa exactamente cada una de las marcas o etiquetas,
diseñar modelos jerárquicos , describir el contenido en forma precisa y así evitar
repeticiones.
• XSD( XML Schemas): XML Schema vence las limitaciones de los DTDs, permite
definir estructuras más complejas que en los DTDs , se puede definir tipos de datos
específicos, por ejemplo no sólo NMTOKEN , #PCDATA o CDATA definidos en los
DTDs.XML Schema, se puede manipular de manera sencilla vía VBScript o en
Páginas 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 gramática de DTDS que son importantes para llegar a nuestro cometido :
• Los esquemas poseen mayor precisión en la definición de tipos de datos
mediante formatos y facetas.
• Los esquemas se definen como documentos XML, en un documento aparte
con extensión .XSD y en los documentos XML que se basen en ese
esquema, incluiremos una referencia al archivo .XSD, esto permite hacer
definiciones genéricas de datos que podrán usadas por varios archivos
XML, dando una ventaja de reutilización 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.
29
Figura 11. Gramática XML
Un ejemplo de un XML Schema quedaría de la siguiente manera para “BloodPressure”:
Código 2 – BloodPressure Schema
30
En este archivo xsd logramos ya definir el tipo de dato para cada atributo correspondiente a
una observación de presión sanguínea:
Position: String
Systolic : int
Diastolic: int
Comment: String
Method: String
No solo definimos los tipos de datos sino que también obligamos a que se respeta la estructura
jerárquica definida en el archivo y si quisiera podría restringir la cardinalidad y las ocurrencias,
por lo tanto todo estudio de la presión respeta esta estructura y la restricción de datos, este
proceso de control se llama validación 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 sintácticas de
XML.
Mientras que un archivo XML Validado: Es aquel que, además de ser bien formado,
sigue las reglas de una gramática (definida en un DTD o XML Schema/ XSD). En el
caso de los XSD específicamente el XML es comparado con un archivo de extensión
XML .xsd en donde se encuentran definidas las estructuras de los datos esta acción es
denominada “Parsing” y las aplicaciones que efectúan la misma son llamados
“Parsers”.
31
Figura 12. Validación 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 manipulación de documentos en XML no es una tarea trivial, se necesitan
aplicaciones que realicen las funciones de análisis, creación, manipulación, entrada y salida
entre otros [8].
En esta sección se analizara los diferentes parsers disponibles y sobre todo su tecnología para
poder ser utilizada en Java.
3.1.2.1 PARSERS
32
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 generación de XML
• El documento XML completo es cargado en memoria y El API incluye métodos
para añadir , borrar o modificar nodos y extremidades
• A diferencia de SAX, DOM permite a los desarrolladores navegar el documento
en cualquier dirección
• El poder adicional que ofrece DOM se traduce en un mayor costo en términos de
uso de memoria
DOM genera un árbol jerárquico en memoria del documento o información en XML,
basándose del documento anterior cada elemento <Data>, <Protocol>, etc. es considerado un
nodo dentro del árbol. Este árbol jerárquico de información en memoria permite que a través
del "parser" ( Xerces [9] o algún otro) sea manipulada la información, las ventajas serían las
siguientes:
Puede ser agregado un nodo (Información) en cualquier punto del árbol.
Puede ser eliminada información 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 especificación existen diversos "parsers" DOM.
Un detalle notorio de cualquier "Parser" es que la mayoría están 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
especificación 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
diseñadas alrededor de JAXP ("Java API for XML Processing") .
3.1.2.1.2 SAX("Simple API for XML")
33
SAX procesa ("parse") el documento o información en XML de una manera muy diferente a
DOM, SAX procesa la información por eventos. A diferencia de DOM que genera un árbol
jerárquico en memoria , SAX procesa efectivamente la información 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 características:
SAX es un "parser" ideal para manipular archivos de gran tamaño, ya que no es
necesario generar un árbol en memoria como en DOM.
Es más rápido y sencillo que utilizar DOM
La sencillez antes mencionada tiene su precio, debido a que SAX funciona por eventos
no es posible manipular información una vez procesada, en DOM no existe esta
limitación ya que se genera el árbol jerárquico en memoria y es posible regresar a
modificar nodos.
La especificación más 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 implementación para DOM como para SAX y
dependiendo de su situación tiene la flexibilidad de utilizar DOM o SAX. Para que sea posible el
migrar o adaptar un programa o aplicación 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 información empiece a
utilizar uno u otro parsers se comporte mejor que otro o quizás descubramos que
determinado "Parser" utiliza menos memoria y es más veloz en ejecución nuestra aplicación lo
que hace delicado el proceso de elección del mismo ya que se deberá hacer una ponderación
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 aplicación de cualquier incompatibilidad, en este caso podremos
lograrlo mediante JAXP el cual que se logra esta independencia de "parsers" XML .
La principal razón detrás de JAXP es precisamente la interoperabilidad "Write once run
everywhere" (Escríbalo una vez ejecútelo en todos lados) de Java, al existir diversos "Parsers"
escritos en Java lo anterior resultaría falso y por esta razón 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 ningún
problema.
34
Otra inclusión en JAXP es TraX que también es un grupo de clases que permiten
interoperabilidad Java entre los diversos XSL Engines , esto permite una migración 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 metodologías SAX y DOM no
fueron diseñadas con Java en mente, con la intención de proporcionar una metodología para
procesar XML más 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 manipulación de esta información, haciendo
transparente el traslado de información 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
manipulación de datos.
Figura 14. Cambio en Arq. Nueva Capa integración
3.2.1 JDOM
JDOM es una biblioteca open source o de formato abierto para la manipulación optimizada de
datos XML con java. A diferencia de los demás Api para la manipulación 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 métodos para la manipulación 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 además de
35
poseer compatibilidad con XML Schema que es condición 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 máquina de estado. DOM no es muy familiar para el programador en Java, pues está
definido en IDL un común denominador a través de lenguajes más 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. Además, no hay una interfaz o clase genérica 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 más incómodas de lo que son en DOM.
JDOM usa constantemente las convenciones de codificación de Java y la biblioteca de clase,
todas las clases primarias de JDOM tienen equals(), toString(), y métodos 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 más fácil y cómodo 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 común para parsear documentos y construir modelos JDOM a partir
36
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 también 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
sólo 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 codificación, los caracteres de fin de línea, espaciado, y
otros detalles de la serialización. 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 también permite
serializar los mismos de nuevo al disco o a un flujo de bytes. Provee numerosas opciones para
especificar la codificación, los caracteres de fin de línea, espaciado, y otros detalles en cuanto a
la serialización. También 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 más natural” Simon
St. Laurent, Autor de XML Elements of Style.
3.2.2 METHOD CORE
MethodCore será el nombre de las librerías principales y funciones que poseerán toda la lógica
de la nueva capa de integración es donde usando el lenguaje java y las capacidades de Jdom se
administrará toda la información en forma de texto mediantes funciones de parseo y
serialización, method core sea una caja negra que poseerá como entra o salida un String XML o
un Objeto que represente cualquier observación.
37
CAPITULO 4 4 CONCEPTOS INVOLUCRADOS
4.1 PATTERNS - PATRONES DE DISEŃO
El uso de patrones ayuda a obtener un software de calidad (reutilización y extensibilidad).Un
catálogo de patrones es un conjunto de recetas de diseño. Aunque se pueden clasificar, cada
patrón es independiente del resto.
Los patrones son soluciones técnicas ya que dada una determinada situación, los patrones
indican cómo resolverla mediante un D.O.O. (Diseño Orientado a Objetos) Existen patrones
específicos para un lenguaje determinado, y otros de carácter más 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 cómo resolver
un problema particular utilizando un pequeño número de clases relacionadas de forma
determinada. No indican cómo diseñar un sistema completo, sino sólo aspectos puntuales del
mismo.
Facilitan la reutilización de las clases y del propio diseño y favorecen la reutilización de clases
ya existentes y la programación de clases reutilizables. La propia estructura del patrón 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 creación, composición y
representación de sus productos.
Cuando un sistema deba ser configurado con una de las múltiples familias de
productos.
Cuando un conjunto de objetos relacionados se diseña para ser usado conjuntamente.
39
Cuando se desea proporcionar una biblioteca de productos de los que sólo se quiere
conocer su interfaz
Aísla las clases concretas.
Permite intercambiar fácilmente familias de Productos.
Proporciona consistencia entre productos.
4.2.1.3 DESVENTAJAS
Dificulta la incorporación 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 métodos definidos y otro(s) abstracto(s), dedicado a la construcción de objetos de un
subtipo de un tipo determinado. Es una simplificación del Abstract Factory, en la que la clase
abstracta tiene métodos concretos que usan algunos de los abstractos; según usemos una u
otra hija de esta clase abstracta, tendremos uno u otro comportamiento.
4.2.2.2 VENTAJAS
Se unen jerarquías de clase paralelas proporcionando relaciones para la creación de subclase
y la extensión.
4.2.2.3 DESVENTAJAS
No se saben de antemano todas las clases que deben ser creadas aplazando la creación de
objetos a las clases con el contexto.
4.2.3 PROTOTYPE
4.2.3.1 DESCRIPCION VENTAJAS
Tiene como finalidad crear nuevos objetos duplicándolos, clonando una instancia creada
previamente .Este patrón aparece en ciertos escenarios donde es preciso abstraer la lógica que
decide que tipos de objetos utilizará una aplicación, de la lógica que luego usarán esos objetos
en su ejecución. Los motivos de esta separación pueden ser variados, por ejemplo, puede ser
que la aplicación deba basarse en alguna configuración o parámetro en tiempo de ejecución
para decidir el tipo de objetos que se debe crear Cuando en un sistema se usen este patrón en
muchos objetos de negocio, conviene tener un prototype manager para preguntarle si tal o
cual objeto es prototípico.
4.2.3.2 DESVENTAJAS
Necesite una familia de objetos de producto relacionados de ser usado juntos y si necesita la
ejecución de esta coacción, necesita un sistema para apoyar múltiples familias de interfaz de
necesidad de clases para crear objetos sin saber sus tipos
40
4.3 PATRONES DE ARQUITECTURA
4.3.1 MVC
El Modelo Vista Controlador es un patrón para el desarrollo del software que se basa en
separar los datos (por un lado), la interfaz del usuario (por otro) y la lógica interna (por un
último lado). Es mayormente usado en aplicaciones web, dónde la vista es la página HTML, el
modelo es el Sistema de Gestión de Base de Datos y la lógica interna, y el controlador es el
responsable de recibir los eventos y darles solución.
A continuación vamos a desgranar más cada elemento:
• Modelo: Es la representación de la información en el sistema. Trabaja junto a la vista
para mostrar la información al usuario y es accedido por el controlador para añadir, 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 más abstracto. Recibe, trata y responde los eventos
enviados por el usuario o por la propia aplicación. Interactuar tanto con el modelo como con la
vista.
4.3.2 Arquitectura en n capas
El Patrón de arquitectura por capas es una de las técnicas más comunes que los arquitectos de
software utilizan para dividir sistemas de software complicados. Al pensar en un sistema en
términos 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 más alta utiliza varios servicios definidos por la inferior, pero la última es inconsciente
de la superior. Además, 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 básicos
Se minimizan dependencias entre capas.
Las capas posibilitan la estandarización de servicios
Luego de tener una capa construida, puede ser utilizada por muchos servicios
de mayor nivel.
41
La imagen que se muestra a continuación presenta el esquema de una
arquitectura siguiendo este patrón:
A continuación se describen las tres capas principales de un patrón de arquitectura por capas:
1. Capa de Presentación: Referente a la interacción entre el usuario y el software. Puede ser
tan simple como un menú basado en líneas de comando o tan complejo como una aplicación
basada en formas. Su principal responsabilidad es mostrar información al usuario, interpretar
los comandos de este y realizar algunas validaciones simples de los datos ingresados.
2. Capa de Reglas de Negocio (Empresarial): También denominada Lógica de Dominio, esta
capa contiene la funcionalidad que implementa la aplicación. Involucra cálculos basados en la
información dada por el usuario y datos almacenados y validaciones. Controla la ejecución de
la capa de acceso a datos y servicios externos. Se puede diseñar la lógica de la capa de
negocios para uso directo por parte de componentes de presentación o su encapsulamiento
como servicio y llamada a través de una interfaz de servicios que coordina la conversación con
los clientes del servicio o invoca cualquier flujo o componente de negocio.
3. Capa de Datos: Esta capa contiene la lógica de comunicación con otros sistemas que llevan a
cabo tareas por la aplicación. Estos pueden ser monitores transaccionales, otras aplicaciones,
sistemas de mensajerías, etc. Para el caso de aplicaciones empresariales, generalmente está
representado por una base de datos, que es responsable por el almacenamiento persistente
de información. 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
42
4.4 FRAMEWORKS J2EE 4.4.1 JSF – JAVA SERVER FACE
Es un framework con tecnología para aplicaciones Java Web basadas en el patrón MVC donde
las vistas conocen la acción que se va a invocar en su petición. Que simplifica el desarrollo de
interfaces de usuario en aplicaciones Java EE [13].
JSF usa Java Server Pages (JSP) como la tecnología que permite hacer el despliegue de las
páginas.
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
navegación de las páginas y dar soporte para internacionalización y accesibilidad.
Un conjunto por defecto de componentes para la interfaz de usuario.
Dos librerías de etiquetas personalizadas para JavaServer Pages que permiten expresar
una interfaz JavaServer Faces dentro de una página JSP.
Un modelo de eventos en el lado del servidor.
Administración de estados.
Beans administrados.
Desde el punto de vista técnico podemos destacar los siguientes:
• JSF forma parte del estándar J2EE, mientras que otras tecnologías para creación 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 estándar que forman el núcleo del framework. Entre estas
implementaciones cabe destacar la implementación de referencia de Sun
Microsystems, actualmente desarrollada como un proyecto open source, y la
implementación 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.
43
4.4.2 ICEFACES
ICEfaces es un Framework Ajax que permite desarrollar Aplicaciones RIA de una manera fácil y
rápida, utilizando el lenguaje Java. Éste está basado en una serie de estándares que permiten
continuar trabajando con la clásica forma de desarrollo con Java. Permite al programador
incluir una serie de Ajax-tags en sus JSP o xhtml de tal manera que el código Ajax es generado
por el propio framework automáticamente.
ICEFaces aísla completamente al desarrollador de AJAX. No hacen falta etiquetas especiales: se
ponen los controles en la pantalla e ICEFaces se encarga de enviar sólo la información
necesaria entre cliente y servidor. Es decir, ya no se envían los formularios a la antigua usanza,
en un POST de HTTP, sino que sólo se envían 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 .
CAPITULO 5 5 METODO FLEXIBLE APLICACIÓN PASO A PASO
Este método 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 creación y modificación impactando
lo menos posible en la estructura de datos original y en las diferentes capas.
En otras palabras la información correspondiente a una observación debe poder persistir en
un campo de tipo String o texto. Esto se podría representar en un ejemplo como una tabla
Observaciones cuyos atributos podrían ser los siguientes:
Figura 17 – Tabla Observaciones
Id Observación: Sera el número identificador de cada observación.
Id Tipo: Sera el identificador que dirá qué tipo de observación es la persistida.
Detalle: Es un atributo del tipo String en formato XML que deberá poseer todos los datos de la
observación propiamente dicha.
En esta tabla que sería perteneciente al modelo total de aplicación y tendrá almacenada toda
la información correspondiente a toda la observación cargada en la aplicación.
Los estados por los que pasaría una observación en su viaje desde un usuario a la base de
datos y viceversa serian:
45
INFORMACION USUARIO
OBSERVACION CLINICA :
Datos de paciente + detalle de la
observación.
Detalle:Conversión de la información a Texto .(XML)
Guardar en la base de
datos.
Figura 18 – Estados de una observación usuario a DB
INFORMACION EN BASE DE
DATOS
PARSEO Conversión de
String en datos de Observacion
Objeto DTOObtener un objeto que posea la
infromacionensus atributos.
Mostrar al Usuario
Figura 19 - – Estados de una observación DB a Usuario
Todos estos estados y los procesos que demanden dentro de la nueva capa de integración
deberán 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 información en la forma que la recibe hasta ahora.
Figura 20 – Capa de Datos + Integración
5.1 Paso 1 Diseño de la estructura de los datos en formato de texto -
CAPA DE DATOS
Plantearemos paso a paso como se debería imprentar el método a partir de un ejemplo
aumentando su complejidad de menor a mayor y justificando los pasos que se toman en cada
caso .
Si deseáramos por ejemplo tomar la presión sanguínea de un paciente cualquiera y los datos
que necesitamos medir fueran los siguientes
46
Posición del paciente al tomar la mediciones
Valor de Presión Sistólica
Valor de Presión Diastólica
El método con el que se haya tomado la misma
Un comentario u observación sobre la medición
Datos que serían una versión 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 serán los encargados de definir la estructura de
estas medidas mediante el leguaje de marcas XML, lo que permitirá en etapas posteriores del
método el poder manipular la información en forma de un String o de texto, el mismo nos
permitirá mediante su semántica definir particularidades como su estructura y sus tipo de
datos.
Para el mismo ejemplo propuesto anteriormente: “presión sanguínea” una definición de sus
datos seria de la siguiente forma:
47
Código 3 - BloodPressure XML Template
El primer archivo cuya extensión será .XML, archivo poseerá la jerarquía y organización de los
datos propios de la observación de presión Sanguínea. Lo primero que se observa que si bien
la distribución y jerarquía están 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 extensión .xsd, ( Un archivo XML con gramática 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 podría ser el siguiente:
48
Código 4 – BloodPressure.xsd
5.2 Paso 2 Creación de una clase DTO
Al observar la estructura de los archivos antes vistos deducimos cual será la información 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 observación nueva y
según su tipo para poder transportar dicha información, para esto una buena opción sería el
utilizar el Patrón DTO. Para nuestro ejemplo deberíamos crear la clase ObservationDTO.java de
la siguiente manera. (Asumimos que cada atributo tiene su método set() y get() y una función
pública vacía)
49
Código 5 – ObservationDTO.Java
De esta manera las instancias de esta clase o mejor dicho los objetos del tipo ObservacionDTO
me servirán para poder llevar a la vista la información de la observación 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 información de las observaciones con las que se
trabajara.
5.3 Paso 3 Parseo y Serialización – Capa de Integración
Básicamente un parseo es un análisis o una conversión. En el caso propuesto será la
conversión 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 través 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,
específicamente corresponderá al atributo Detalle de la tabla ejemplo. Este proceso es
llamado serialización
Para eso se podrá definir una clase a la cual podríamos llamar Analizer.java que
Implementara 2 métodos un método parser() que recibirá el String y devolverá un objeto del
tipo ObservationDTO y un método serialize() que recibirá el objeto y devolverá un String XML
y a estos dos métodos se agregara un método validate que será el encargado de validar la
gramática de los XML Schema o archivos xsd.
50
Diagrama 1 – Analizer Class
5.3.1 METODO PARSE()
EL método parse() tendrá la siguiente firma public ObservationDTO parse(String XML) este
recibirá el String XML del tipo de observación requerido. El mismo realizara los siguientes
pasos:
En primer lugar se validará el String que posee la información para asegurarnos su
buena formación en XML y la validación de con las reglas del Schema correspondiente.
Creará un objeto del tipo Document de JDOM a partir del cual podremos obtener su
raíz 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
observación.
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 y su método parser() se implementaría de la siguiente
manera:
51
Código 6 – Iparseable.Java
5.3.2 METODO SERIALIZE() o Serialización
EL método serialize() tendrá la siguiente firma public String serialize(IParseable
dtoObservation, String xmlTemplate), este recibirá el objeto DTO del tipo de observación
correspondiente para transformarlo en String, el cual será persistido en la base de dato. Un
detalle de este método es que el mismo recibirá como parámetro una plantilla (template)
como referencia, o sea un objeto XML String vacío correspondiente al tipo de observación
que se quiere transformar a String.
Este método seguirá los siguientes pasos:
En primer lugar se validara la plantilla que posee la información para asegurarnos su
buena formación en XML y su validación.
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 parámetro.
Retornaremos el String XML a persistir.
Particularizado para nuestro ejemplo seria:
52
Código 7 – Método Serialice ()
Existen consideraciones a tener en cuenta en cuanto a el analyzer.java las funciones no
hacen el control de con qué tipo de observación se está trabajando ya que se deberá crear un
objeto analizer para cada tipo de observación.
5.4 Paso 4 Persistencia en la base de datos - Capa de Integración
Una vez que ya tenemos las clase y métodos 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 información y obtener o el texto para el atributo detalle en la tabla
observación, ahora deberemos crear la respectivas clases para poder persistir en la base de
datos la información en la tabla observaciones.
Por ende la tabla base de datos tendrá su propia clase para persistir los datos y un método
setDetail (String cadena) y métodos como créate, update o delete que serán los encargados
de la administración 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 podría crea una clase
ObservationDAO encargada de los siguientes métodos.
Guardar una observación
Modificar una observación
Eliminar una observación
Obtener una observación a partir de un String.
53
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 observación y por supuesto el detalle
resultante de llamar a la función parser. Nota: Se podrá crear una factoría que será la
encargada de entregar la plantilla vacía en base al tipo de observación a parsear
Código 8 – AddObservatinDB ()
5.4.2 Modificar una observación en la Base de datos
En este método debemos obtener los datos de la observación guardada y luego sobrescribir
los datos a modificar que se encuentren en el objeto del tipo ObservationDTO, para nuestro
ejemplo el método seria:
54
Código 9 – updateObservationDB()
5.4.3 Eliminar y obtener Observación
A su vez los métodos eliminar y obtener tendría esta forma.
Código 10 – deleteObservationDB()
55
Código 11 – getObservation()
5.5 METODO GENERALIZADO
En base a lo anterior observamos que para la creación de cualquier observación deberemos
seguir los siguientes pasos:
1. Diseño de los datos, es decir la generación de 2 archivos de texto que respetaran la
gramática de XML Schemas:
a. .XML: Donde se encuentran los datos propiamente dichos de una observación.
b. .xsd: Define la estructura de los datos como los tipos de los mismos y/o
relaciones entre los tipos de datos.
2. Creación de una clase DTO que refleje los datos a obtener y persistir en la base de
datos o mostrar al usuario
3. Creación de métodos de parseo y serialización que se encargaran del análisis de los
archivos XML.
4. Creación de una clase que implemente métodos de persistencia en la base de datos
por cada observación
El código mostrado en el ejemplo esta particularizado para una sola observación, no estaría
visto desde una perspectiva de desarrollo en grupo o una escalabilidad considerable.
En un caso real, la aplicación no solo manipulara varias observaciones si no que las mismas
cambiaran en la línea del tiempo y se agregaran muchas otras y por ende estos pasos deberían
generalizarse de manera de abstraerse de ciertas complicaciones y generar una serie de pasos
sencillos y casi mecánicos a la hora de agregar una observación.
Para llegar a nuestro objetivo deberemos explotar conceptos muy fuertes de la Diseño y la
programación orientada a objetos tales como herencia, encapsulamiento y Atracción.
5.5.1 Herencia
La herencia es un mecanismo que permite la definición de una clase a partir de la definición de
otra ya existente. La herencia permite compartir automáticamente métodos y datos entre
clases, subclases y objetos.
56
La herencia está fuertemente ligada a la reutilización del código en la OOP. Esto es, el código
de cualquiera de las clases puede ser utilizado sin más 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 través del uso de herencia, los programadores pueden reutilizar el código
de la superclase muchas veces.
Los programadores pueden implementar superclases llamadas clases abstractas que definen
conductas "genéricas". Las superclases abstractas definen, y pueden implementar
parcialmente, la conducta pero gran parte de la clase no está definida ni implementada. Otros
programadores concluirán esos detalles con subclases especializadas.
Hay dos tipos de herencia: Herencia Simple y Herencia Múltiple. 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 más clases iniciales. Java sólo
permite herencia simple, sin embargo la herencia múltiple es implementada a través de la
Interfaces las cuales servirán en nuestro caso para poder crear contratos que respetaran todas
las clases que implemente una misma interface.
5.5.2 Encapsulamiento
El encapsulamiento es básicamente el empaquetamiento de las variables de un objeto con la
protección de sus métodos. Típicamente, el encapsulamiento es utilizado para esconder
detalles de la puesta en práctica, 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 métodos en un componente de software ordenado es,
todavía, una simple idea poderosa que provee dos principales beneficios a los desarrolladores
de software:
Modularidad, esto es, el código fuente de un objeto puede ser escrito, así como darle
mantenimiento, independientemente del código fuente de otros objetos pudiendo ser
planificado por diversos programadores sin que estos dependan del funcionamientos de los
otros módulos 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 información, es decir, un objeto tiene una "interfaz publica" que otros
objetos pueden utilizar para comunicarse con él. Pero el objeto puede mantener información y
métodos privados que pueden ser cambiados en cualquier tiempo sin afectar a los otros
objetos que dependan de ello.
57
Los objetos proveen el beneficio de la modularidad y el ocultamiento de la información. Las
clases proveen el beneficio de la reutilización. Los programadores de software utilizan la
misma clase, y por lo tanto el mismo código, una y otra vez para crear muchos objetos.
5.6 OBSERVACIONES CLÍNICAS
Para poder observar el comportamiento propondremos un nuevo tipo de observación “Body
Temperture” o temperatura corporal, el esquema propuesto por OpenEHR sería el siguiente:
Figura 22 –BodyTemperature OPENEHR
Una vez más tomaremos una versión reducida del mismo y los datos a obtener serian:
BodyExposure: exposición del cuerpo
Temperature: temperatura
Device: dispositivo con el que fue medido.
Figura 23 - BodyTemperature version reducida.
La versión de XML y XSD seria
58
Código 12 – BodyTemperature.xml
Xsd:
Código 13 – BodyTemperature.xsd
Podemos notar en las definiciones como es que una observación posee distintos tipos de datos
pero al a vez un criterio de agrupación de los mismos como son los grupos DATA, PROTOCOL,
etc.
59
Una vez mas no solo se definen los tipos de datos sino que también obliga a que se respete la
estructura jerárquica definida en el archivo y si se quisiera se podría restringir la cardinalidad
como el nivel de anidamiento requerido, por lo tanto toda observación clínica de la presión
deberá respetar esta estructura y la restricción de datos para ser un archivo XML validado.
Al poseer ya dos o más tipos se necesita el buscar formas de generalizar los pasos antes
propuesto para poder de alguna forma controlar la población de observaciones dentro del
sistema y que su creación no llego a lo complejo.
5.7 APLICACIÓN DE INTERFACES
Las interfaces describen el comportamiento que poseen muchas clases distintas, en otras
palabras una interfaz es una colección 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 sólo una parte
del mismo. Una interfaz describe un conjunto de especificaciones de operaciones (o sea, su
signatura) pero nunca su implementación. Esta característica del modelado Orientado a
Objetos nos permitirá generalizar e independizarnos de la implementación en sí de cada una
de las clases, las interfaces utilizas para este caso serían las siguientes.
El uso de interfaces proporciona las siguientes ventajas:
Organizar la programación (IAJU).
Obligar a que ciertas clases utilicen los mismos métodos (nombres y parámetros).
Establecer relaciones entre clases que no estén relacionadas.
La principal diferencia entre interface y abstract es que un interface proporciona un
mecanismo de encapsulación de los protocolos de los métodos sin forzar a utilizar la
herencia.
5.7.1 INTERFACES – Iparseable
La interface Iparseable será una interface vacía la cual será implementada por todas las clases
que represente a los DTO de cada observación es decir de alguna manera su único objetivo
será agrupar en un mismo tipo de dato a todos los objetos que deberán ser parseados o
serializados, o dicho de otra manera crear el grupo de los objetos a ser serializados o
parseados.
60
Diagrama 2 – Interface IParseable
Un ejemplo de código seria el siguiente:
Código 14 – BodyTemperature DTO
5.7.2 INTERFACES – IAnalizable
La interfaces IAnalizable será la encargada de crear un contrato que deberán respetar todas las
clases encargadas del análisis de los datos en formato XML. La creación de esta interface me
facilitará la independencia en cuanto a la tecnología con la que se implementaran de los
métodos pudiendo cambiar el API o parsers utilizados actualmente por algún otro en otro
momento sea más conveniente y no necesariamente JDOM el cual es nuestra elección actual.
Observaremos que la creación de esta interface y la generalización de sus métodos se hacen
posibles solo gracias a la creación de la interface IParseable la cual es usada por IAnalizable.
61
Código 15 – Implements IAnalizable
IAnalizable:
Diagrama 3 – Interface IAnalizable
62
Código 16 – Contrato de IAnalizable
5.8 IMPLEMENTACION DEL PATRÓN FACTORY
Factory proporciona una interfaz para crear familias de objetos relacionados o dependientes
sin especificar sus clases concretas. Nos proporcionara las siguientes ventajas:
Aísla las clases concretas.
Permite intercambiar fácilmente en los grupos de datos.
Proporciona consistencia entre tipos de Observaciones.
Este patrón proveerá un método para la obtención de cada objeto de su familia así como la
creación 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 aplicación deberá poseer una forma por el cual
identificar que clase analizer utilizar en base al tipo de observación con la que se esté
trabajando, para eso se utilizara el patrón Factory el cual creara una instancia del Analizer
correspondiente en base al tipo que se solicite.
63
Diagrama 4 – Analizer Factory
EL código de implementación seria (AnalyzeFactory.java):
Código 17 - AnalyzeFactory.java
5.8.2 FACTORY – TemplateFactory
Al generar un archivo XML y un XSD para cada observación 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 algún modo en que la aplicación sepa que
template o plantilla a utilizar en base al tipo de observación. En base al patrón Factory se
64
creara una clase que genere una instancia de esquema en base al tipo de observación.
Diagrama de objeto:
Diagrama 5 – Template Factory
Código 18 - Template Factory
65
5.9 IMPLEMENTACION DEL PATRÓN DAO
Los Objetos del tipo DAO manejan la conexión con la fuente de datos para obtener y
almacenar datos, es decir lo referente a la persistencia.
El uso de este patrón ofrecerá varios beneficios para la persistencia de datos:
Servirá para separar el acceso a datos de la lógica 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 integración.
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 lógica del desarrollo.
Por lo tanto, al realizar una operación, se abrirá la conexión a la base, se ejecutara el comando,
si es una operación de lectura, se volcara el contenido hacia una estructura de datos y se
cerrara la conexión.
5.9.1 INTERFACES – IObservationDAO
Esta interface será la encargada del contrato de los métodos de persistencia en la base de
datos, en este caso su único objetivo será independizarme de la tecnología con la que se
persiste. La implementación de la persistencia cambiara un poco en cuanto a las formas de sus
métodos más que nada ya que ahora solo con enviar el Id del tipo de observación y gracias a
que se implementa factorías para las creación de los Analizers y de los templates se tendrá
una sola clase DAO la cual poseerá métodos que con solo enviar el id del tipo de observación
con la que se desea persistir identificara la misma para utilizar el analizar y el template que le
corresponda.
Diagrama 6 - ObservationDAO
El código de IObservationDTO seria:
66
Código 19 - IObservationDTO
La implementación de esta interface seria la siguiente:
Código 20 - ObservationDAO
67
68
Código 21 – ObservationDAOImp
69
5.10 DIAGRAMA DE CLASES
Diagrama 7 – Diagrama de clases MethodCore
5.11 CONCLUSIONES DE LA GENERALIZACIÓN
La solución 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 información.
Al poder dar formato a mi información 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 creación de cualquier observación deberemos seguir los
siguientes pasos:
1. Diseño de los datos, es decir la generación de 2 archivos de texto que
respetaran la gramática de XML Schemas, dichos archivos serán guardado
70
en la base de dato como atributos tipo TEXT o BLOB, ya sea en forma de
template o con el detalle de observaciones.
2. Creación 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. Creación de una clase que implemente la interface IAnalizable por ende
los métodos de parseo y serialización que se encargaran del análisis y
conversión de los archivos XML con el detalle de cada observación.
4. Agregar condiciones correspondientes en clases Factory, simplemente se
agregara una o 2 líneas de código según corresponda a cada una de las
clases factorías para el tipo de observación especifica.
Lo Que deberemos notar es que la creación de una clase DAO solo se efectuara una vez ya que
ella solo dependerá del id del nuevo tipo de Observación en la tabla observaciones.
5. Creación de métodos de persistencia en la base de datos a partir de la implementación
de la interface IObservationDAO.
De esta manera cada desarrollador solo deberá seguir los paso o trabajar en cualquier de
ellos indistintamente hasta completar todos.
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 versión 3. Estas herramientas aportan benéficos tales como el poder
utilizar tecnologías como AJAX [15] acrónimo de Asynchronous JavaScript And XML (JavaScript
asíncrono y XML), permite crear aplicaciones más interactivas y rápidas. Y las hojas de estilo
CSS (Cascading Style Sheets)[16]. Entregando un diseño dinámico. Y como resultado despegar
la presentación del contenido.
Sin embargo la creación 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 presión correspondiente a un paciente en especial y mucho mayor, aun, en caso que
se deba comparar más de una observación en la misma vista.
En base a este problema, si se pudiera usar plantillas para las vistas de cada observación,
se podría, también, hacer una anidación de las mismas y la reutilización de código de por
medio; es decir crear una vista y poder utilizarla una y otra vez, combinándola con sus pares
creando vistas complejas a partir de vistas independientes. Esto disminuiría el problema de la
mantención del sistema, como así también, la generación 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 tecnología JSF y viene ya incluido en la última versión
de JSF 2, versión que forma parte de la nueva migración de la aplicación. El mismo es un
complemento perfecto de icefaces ya que incorpora nuevas funciones fáciles de desarrollar,
siendo un perfecto componente para trabajar con las tecnologías utilizadas en nuestro
sistema. Facelet también utiliza la creación 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, según la necesidad.
72
Esto daría la posibilidad de crear nuevas API´s que generen automáticamente las vistas
tomando como punto de partida los archivos xml que definen la estructura de observaciones
clínicas.
Basado en los ejemplos anteriores estas cualidades de facelet llevarían a tener una
correspondencia de uno a uno con la definición de la estructura, en este caso con
BloodPressure.xsd; dando la ventaja de agregar solo una plantilla nueva (facelets template)
por cada observación agregada quedando casi intacta la interacción de las antiguas vistas
haciendo que sea sencilla tanto su creación como su mantenimiento y/o modificación. De esta
manera gracias a los cambios en el modo de persistencia se mejoraría el desarrollo de y la
implementación de las vistas o de las presentaciones de estas observaciones.
Figura 24 -Se puede crear una relación directa entre las vistas y las
estructura y combinar las vistas según sea necesario.
CAPITULO 7 7 CONCLUSIONES
Se utilizaron alternativas basadas en software libre, cuyo conjunto brinda flexibilidad a la hora
de administrar y visualizar la información referente a observaciones clínicas.
Se logró independizar las estructuras de datos de las reglas del modelo relacional tradicional.
Se reduzco el impacto que produce la administración y sobre todo la creación de nuevas
observaciones clínicas, en las capas del sistema inicial, explotando la potencialidad y
flexibilidad del lenguaje XML.
En base al nuevo diseño se creó un conjunto de librerías que pueden ser usadas por la
aplicación actual una vez se produzcan los cambios propuesto en la arquitectura, este “núcleo”
de librerías 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 información
dentro de la aplicación, haciendo hincapié en la reutilización de código y fácil mantenimiento
del mismo.
“Se propuso solucionar problemas de forma innovadora empleando tecnologías simples para
atender las problemáticas aún 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 Andrés,"BASES DE DATOS MULTIMEDIA", ETIS, 2005.
[4] "http://www.openehr.org", Documentación online, Sitio de la fundación openEHR.
[5] Grigoris Antoniou and Frank van Harmelen, "A Semantic Web Primer - Second edition" ,
The MIT Press Cambridge, Massachusetts, London, England, 2008.
[6] Daniel Martínez Ávila, "Tendencias y usos de XML en Biblioteconomía y
Documentación",Master en Investigación en Documentación 2008.
[7] Introducción 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), Documentación.
[10] Jason Hunter (Co-Creator JDOM Project), "JDOM Makes XML Easy",JavaOne, Sun`s
Worldwide Java Developer Conference, 2002.
[11] http://www.jdom.org, Documentación 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/", Documentación online, Sitio de Sun
Microsystems sobre la tecnología Java Server Faces.
[14] "http://www.icefaces.org/",Documentación online, Sitio de ICE soft Technologies Inc.
Sobre tecnología 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/", Documentación online, Sitio Recomendaciones W3C.
[17] Bruno Aranda and Zubin Wadia, "Facelets Essentials Guide to JavaServer Faces View
Definition Framework", First Press, 2008.
75
