P. 1
Tesis de Grado - "Método Flexible de Persistencia de Observaciones Clínicas"

Tesis de Grado - "Método Flexible de Persistencia de Observaciones Clínicas"

|Views: 20|Likes:
Presentación PREZI : http://prezi.com/8r_oawxcyuby/metodo-flexible-de-persistencia-tesis-de-grado/?auth_key=662ddd553cf21b81d91c8c260da218b0d408c1ac
Presentación PREZI : http://prezi.com/8r_oawxcyuby/metodo-flexible-de-persistencia-tesis-de-grado/?auth_key=662ddd553cf21b81d91c8c260da218b0d408c1ac

More info:

Published by: Darwin Rodrigo Zottola Pareja on Jan 07, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/07/2014

pdf

text

original

UNIVERSIDAD NACIONAL DE TUCUMÁN FACULTAD DE CIENCIAS EXACTAS DE Y TECNOLOGÍA ELECTRICIDAD

,

DEPARTAMENTO

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

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.-

2

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.

3

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 1.2 PROBLEMÁTICA - MOTIVACIONES............................................................................ 12 OBJETIVOS ............................................................................................................... 14 Objetivos Principal ........................................................................................... 14 Objetivos generales ......................................................................................... 14

1.2.1 1.2.2 2

APLICACIÓN WEB PARA TELEMEDICINA CHASQUI ........................................................... 17 2.1 2.2 2.3 2.4 2.5 2.6 2.7 ARQUITECTURA ....................................................................................................... 17 TECNOLOGIAS ACTUALES ........................................................................................ 18 MODELO FUNCIONAL .............................................................................................. 18 PROBLEMÁTICA ACTUAL .......................................................................................... 20 OBSERVACIONES CLÍNICAS COMO INFORMACIÓN ................................................... 21 EL MODELO DE BASE DE DATOS RELACIONAL Y SU PROBLEMÁTICA ........................ 23 ANALISIS DE ESTADO ............................................................................................... 24 Puntos Críticos: ................................................................................................ 24 Puntos Fuertes ................................................................................................. 24

2.7.1 2.7.2

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

3.1.1 3.1.2 3.2

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

3.2.1 3.2.2 4

CONCEPTOS INVOLUCRADOS .......................................................................................... 38 4.1 PATTERNS - PATRONES DE DISEŃO .......................................................................... 38 DAO- DTO ........................................................................................................ 38 4

4.1.1

4.2

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

4.2.1 4.2.2 4.2.3 4.3

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

4.3.1 4.3.2 4.4

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

4.4.1 4.4.2 5

METODO FLEXIBLE APLICACIÓN PASO A PASO ................................................................ 44 5.1 5.2 5.3 Paso 1 Diseño de la estructura de los datos en formato de texto -CAPA DE DATOS .. 45 Paso 2 Creación de una clase DTO ........................................................................... 48 Paso 3 Parseo y Serialización – Capa de Integración ................................................. 49 METODO PARSE() ............................................................................................. 50 METODO SERIALIZE() o Serialización ................................................................ 51

5.3.1 5.3.2 5.4

Paso 4 Persistencia en la base de datos - Capa de Integración ................................ 52 Guardar en la Base de Datos ............................................................................ 53 Modificar una observación en la Base de datos ................................................ 53 Eliminar y obtener Observación ....................................................................... 54

5.4.1 5.4.2 5.4.3 5.5

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

5.5.1 5.5.2 5.6 5.7

OBSERVACIONES CLÍNICAS....................................................................................... 57 APLICACIÓN DE INTERFACES .................................................................................... 59 INTERFACES – Iparseable.................................................................................. 59 INTERFACES – IAnalizable ................................................................................. 60

5.7.1 5.7.2 5.8

IMPLEMENTACION DEL PATRÓN FACTORY............................................................... 62 FACTORY – AnalizerFactory .............................................................................. 62 FACTORY – TemplateFactory ............................................................................ 63

5.8.1 5.8.2 5.9

IMPLEMENTACION DEL PATRÓN DAO ...................................................................... 65 INTERFACES – IObservationDAO....................................................................... 65

5.9.1 5.10 5.11

DIAGRAMA DE CLASES ............................................................................................. 69 CONCLUSIONES DE LA GENERALIZACIÓN ................................................................ 69 5

6

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

7

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

8

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

6

Í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

7

Í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

8

Í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

9

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

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.

11

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

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 Observaciones [3]. que son necesarias formar para cado uno de estas

Dichas observaciones no solo poseen una familia muy grande de tipos que necesitan ser manipulados si no que sus estructuras a la hora de ser representadas fehacientemente dentro de un modelo relacional puede variar desde estructuras muy simples que se resumen a una entidad, como relaciones complejas de varias de ellas y su respectiva cardinalidad u ocurrencias. A todo esto 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 13

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 objetivo de este proyecto se basa en Implementar una metodología de En primer el

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. 14

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.

15

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

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 18

paciente. Por otro lado el (o los) especialista(s), que desde hospitales centrales o desde cualquier dispositivo por el que pueda acceder a la web aporta sus conocimientos basado en el intercambio de 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. 19

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 20

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 .

21

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. 22

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 7. Representación relacional de una Observación

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. 23

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.  2.7.2 Impacta en todas las capas de la arquitectura actual.

Puntos Fuertes  Frameworks de desarrollo utilizados basados en tecnologías XML (Extensible Markup Language).

24

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.

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 26

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

Abierto: independiente de plataformas, empresas, lenguajes de 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 27

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. 28

Figura 11. Gramática XML

Un ejemplo de un XML Schema quedaría de la siguiente manera para “BloodPressure”:

Código 2 – BloodPressure Schema

29

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”. 30

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 31

3.1.2.1.1 DOM (Document Object Model) • • • • El API está estandarizada por elW3C (http://www.w3c.org) Disponible para varios lenguajes Tiene soporte para 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") 32

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. 33

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 34

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 35

de estos. JDOM viene con Xerces 1.4.4, pero puede trabajar de igual manera con cualquier parser compatible con SAX2 incluyendo Crimson, AElfred (el parser de Oracle XML para Java), Piccolo, Xerces-2. Cualquiera de estos puede leer un documento XML y ponerlo en JDOM y puede 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.

36

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 productos.  Cuando un conjunto de objetos relacionados se diseña para ser usado conjuntamente. con una de las múltiples familias de

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 39

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. 40

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

41

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.

42

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 .

43

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:

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 DTO Obtener un objeto que posea la infromacion ensus 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 45

    

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:

46

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 47 ser el siguiente:

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) 48

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. 49

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 manera: y su método parser() se implementaría de la siguiente

50

Código 6 – Iparseable.Java

5.3.2

METODO SERIALIZE() o Serialización public String serialize(IParseable

EL método serialize() tendrá la siguiente firma

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: 51

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. 52

5.4.1

Guardar en la Base de Datos

Particularizado para nuestro ejemplo debemos primero crear un objeto del tipo ObservationDTO en el cual se cargara el tipo de 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:

53

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()

54

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. 55

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. 56

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 57

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. 58

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. 59

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. 60

Código 15 – Implements IAnalizable

IAnalizable:

Diagrama 3 – Interface IAnalizable

61

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.

62

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 63

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

64

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: 65

Código 19 - IObservationDTO

La implementación de esta interface seria la siguiente:

Código 20 - ObservationDAO

66

67

Código 21 – ObservationDAOImp

68

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 69

en la base de dato como atributos tipo TEXT o BLOB, ya sea en forma de template o con el detalle de observaciones. 2. 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.

70

ESCALABILIDAD
6 ESCALABILIDAD
Como ya se dijo anteriormente , la capa de control esta implementada con Java Server Faces (JSF) particularmente mediante el framework ICE Faces 1.8 que en la actualidad esta siendo migrado a la 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.

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.

72

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 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. las capas del sistema inicial, explotando la potencialidad y

“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

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->