En el ejemplo 11.2, se muestra el fragmento de un posible mensaje XML que se intercambiaría entre dos sistemas y que contendría la información relativa a las clases ReusableDevice, ManufacturedDevice y Device que han aparecido en los ejemplos anteriores.
Para componer el mensaje correctamente, hay que tener en cuenta que todos aquellos atributos obligatorios deben aparecer, y que aquellos que son de tipo código, como el typeCode y el classCode, que determinan la clase que los contiene, no deben definirse puesto que su valor queda implícito.
<reusableDevice>
<time value="20101117124128"/>
<ManufacturedDevice>
<id root="1" extension="12345"/>
<Device>
<id root="1" extension="1234"/>
<name>Device 1</name>
</Device>
</ManufacturedDevice> </reusableDevice>
92
HERRAMIENTA DE
93
12 ESPECIFICACIÓN
En el bloque que se inicia con este capítulo, se explica todo lo relacionado con la herramienta de transformación de modelos. Esto incluye su proceso de desarrollo, los problemas que presenta el estándar HL7 y que lo han dificultado, ejemplos de conversiones, guías tanto a nivel de usuario como a nivel de administrador, un pequeño estudio sobre el rendimiento de la aplicación y finalmente cómo se ha usado la herramienta UmlCanvas para hacer que los esquemas resultantes más accesibles.
En este capítulo concreto, se describe el proceso de desarrollo del software que transforma modelos de HL7 en modelos UML. Dicho proceso, consta de diversas fases claramente diferenciadas. Con el fin de poder exponerlo de forma clara, se ha optado por hacer una breve introducción, donde se describen de forma resumida cada una de estas fases y más adelante, ofrecer un capítulo dedicado a cada una de ellas, donde se presentan detalladamente.
En la figura 12.1, se muestra un esquema que permite distinguir con claridad todos los elementos que intervienen en el desarrollo de la herramienta. A partir de dichos elementos, resulta sencillo distinguir cuáles son las fases que componen el proyecto.
Figura 12.1 Esquema general de la herramienta de conversión de modelos
94
Metamodelo HL7. Los modelos disponibles en el estándar HL7, se rigen por toda una serie de
normas y restricciones definidas implícitamente. El primer paso que debemos dar, consiste en diseñar un metamodelo que refleje todas esas características y del cual, todos los modelos disponibles en el estándar se puedan considerar instancias. El formato que se ha escogido para representarlo es el Ecore, el lenguaje propio de la herramienta Eclipse para definir metamodelos. Como se verá en el capítulo dedicado al metamodelo de HL7, el diseñarlo nos ayudará tanto a la hora de definir las reglas que nos permiten pasar de HL7 a UML, como al tratar los ficheros del estándar que contienen la información de los modelos HL7.
Archivos MIF del estándar. La información de los modelos del estándar HL7, se encuentra
disponible en distintos formatos. En el proyecto que nos ocupa, se ha optado por utilizar los archivos MIF (Model Interchange Format). En su capítulo correspondiente, se explicarán las distintas opciones que se han valorado en el desarrollo del proyecto y se justificarán las decisiones tomadas.
Modelos HL7. Se necesita tratar los archivos MIF, para a partir de ellos, poder generar
instancias escritas en XML del metamodelo HL7 anteriormente descrito. Para esta tarea, se ha optado por desarrollar un parser codificado en Java. El hecho de tener el metamodelo descrito en Ecore, nos facilita esta tarea de forma considerable, puesto que Eclipse a partir de él, es capaz de generar una API que nos permite tratar de una forma simple con los elementos que aparecen en dicho metamodelo.
Metamodelo UML. Este metamodelo, resulta necesario para definir las reglas de conversión
correctamente, ya que el objetivo consiste en que los modelos resultantes sean instancias suyas, o lo que es lo mismo, que sean válidos según la especificación de UML. Este metamodelo no lo hemos tenido que diseñar nosotros mismos. Como se ha explicado anteriormente, la Object Management Group (OMG), organización que promueve diversos estándares entre los que se encuentran el UML, se encarga del diseño de dicho metamodelo, y diversos grupos de desarrollo de Eclipse, de generar su versión en formato Ecore.
Reglas de transformación ATL. ATL es una herramienta de transformación de modelos
construida sobre Eclipse, que permite, dados dos metamodelos MM1 y MM2, una instancia de MM1 escrita en XML y una serie de reglas de conversión de MM1 hacia MM2, generar una instancia de MM2 también escrita en XML, la cual contiene la información transformada de la instancia de MM1 una vez se aplican las reglas para pasar de MM1 a MM2. Este conjunto de reglas constituye la parte central del proyecto, pues es donde se definen las transformaciones necesarias para obtener los modelos UML.
95
Modelos UML. Al final del proceso, obtenemos un archivo XMI que es instancia del
metamodelo UML, o dicho de otra manera, un modelo válido según las reglas definidas por UML, y que contiene la misma información que el archivo MIF de origen.
Modelos UML refinados. Existen ciertas características que nos gustaría que los UML
resultantes incorporasen, pero que no podemos obtener simplemente aplicando las reglas ATL. Estos aspectos tienen que ver, principalmente, con la forma de referenciar elementos que se encuentran definidos en otros ficheros UML. Por este motivo, resulta necesario desarrollar una pequeña aplicación que corrija estos pequeños detalles, generando nuevos ficheros UML a partir de los obtenidos al aplicar las reglas de transformación.
A partir de los elementos descritos, resulta lógico dividir el trabajo realizado en el desarrollo de la herramienta en cuatro fases claramente diferenciables:
En la primera de ellas, tiene cabida todo aquello relacionado con el diseño del metamodelo de HL7.
En la segunda, se encuentran los aspectos que tienen que ver con el trato de los archivos MIF y su conversión a un archivo XML que sea instancia del metamodelo HL7 diseñado.
En la tercera, se trata la definición de las reglas de conversión de la herramienta ATL.
En la cuarta y última, es en la que se refinan los UML que se obtienen al aplicar las reglas ATL.
En la figura 12.2, se muestra un esquema en el que se puede apreciar cómo se relacionan estas cuatro fases entre ellas. Además, se pueden distinguir las entradas que reciben y las salidas que generan.
96
Figura 12.2 Fases del proyecto
A continuación, tal y como se ha afirmado anteriormente, se procede a explicar cada una de las cuatro etapas de desarrollo en un capítulo propio.
97
13 METAMODELO DE HL7
En este capítulo, se expone todo aquello relacionado con el diseño del metamodelo de HL7. Dicho metamodelo no se puede encontrar de forma explícita en el estándar HL7. Es decir, no encontramos ningún documento o esquema único donde se describan todos los elementos que lo componen. No obstante, analizando los distintos esquemas conceptuales que ofrece y la gran cantidad de documentos donde se explican detalles de sus elementos, resulta viable deducirlo. Esto es, precisamente, lo que se ha hecho en este proyecto y en este mismo capítulo, se justificarán todas las decisiones de diseño tomadas.
Por otro lado, la necesidad de diseñar este metamodelo, resulta fácilmente justificable por tres razones:
La primera es que resulta imprescindible para poder utilizar la herramienta de transformación de modelos ATL.
La segunda es que a partir de él, Eclipse es capaz de generar automáticamente una API que nos ayuda a tratar todos los archivos MIF del estándar, que constituyen la fuente a partir de la cual se extrae la información de los modelos.
Por último, resulta muy útil de cara a poder asegurarnos nosotros mismos de que entendemos todos los elementos que componen el estándar y las relaciones que se dan entre ellos, ya que a partir de la instanciación de modelos, podremos comprobar si se ha definido correctamente o no.
En la sección que se presenta a continuación, se explica cómo se ha diseñado el metamodelo, analizando cada uno de los elementos que se incluyen en el estándar de forma separada. También se proporcionan explicaciones sobre las herramientas usadas para definirlo y algunos ejemplos de instanciaciones de esquemas, que nos permitirán garantizar que se ha definido correctamente.