Un Enfoque de Fábrica de Software a Soluciones de HL7 Versión 3

Junio 2005

Publicado: 18 de diciembre de 2006

Traducido por Victor Garcia Aprea

Este artículo no ha sido traducido por Microsoft

Este artículo y la veracidad de su traducción no ha sido revisado o verificado por Microsoft.

Microsoft no acepta responsabilidades sobre la veracidad o la información de este artículo que se proporciona tal cual por la comunidad.

Sumario: Este articulo, escrito por Microsoft en colaboración con Blueprint Technologies [BPT] como parte de la iniciativa “Health Level 7 (HL7) Software Factory” de Microsoft, presenta una vision de una fábrica de software en el contexo de la versión 3 de Health Level Seven.

La implementación de una fábrica de software sobre HL7, como se describe en este artículo, esta orientada a ser utilizada por desarrolladores de aplicaciones HL7 versión 3 para simplicar la especificación, diseno, implementación, testing y deployment de aplicaciones compatibles con HL7 v3. Una visión más específica sobre la fábrica en cuestión sería:

Desarrollar una Fábrica de Software que simplifique a los proveedores de soluciones de Helathcare la arquitectura, disenio, e implementación de aplicaciones compatibles con HL7 v3 dentro de un ambiente de Servicios web que es construido utilizando herramientas de Microsoft y componentes de la plataforma base.

Antes de comenzar a describir en detalle la vision de esta fábrica un panorama general sobre la vision de Microsoft acerca de fábricas en general es provisto.

En esta página

Fábricas de Software Fábricas de Software
Introducción Introducción
Problemas crónicos del desarrollo de software Problemas crónicos del desarrollo de software
Visión sobre la fábrica de software para HL7 Visión sobre la fábrica de software para HL7
Panorama Panorama
Activos existentes Activos existentes
Imposiciones Imposiciones
Interesados Interesados
Contexto Contexto
El Problema El Problema
La Solución La Solución
La Arquitectura La Arquitectura
El proceso de desarrollo de aplicaciones y las herramientas utilizadas El proceso de desarrollo de aplicaciones y las herramientas utilizadas
El esquema de una fábrica de software El esquema de una fábrica de software
La fábrica de software de HL7 como ejemplo La fábrica de software de HL7 como ejemplo
Referencias Referencias

Fábricas de Software

Los contenidos de esta sección son un sumario de otras fuentes (ver [GR+A04], [GR+J04], y [GS+SD04]) acerca de la estrategia de Fábricas de Software de Microsoft.

Una discusión más detallada es provista en el libro “Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools” escrito por Jack Greenfield y Keith Short, de la editorial John Wiley and Sons [GS04]. Más información puede ser también obtenida visitando los sitios web MSDN Software Factories y Software Factories aquí.

Introducción

Los requerimientos y tecnologias, cada vez más complejos y en constante cambio, estan exigiendo los límites de los actuales métodos de desarrollo de software. Debido a esto los Interesados se estan inclinando cada vez más hacia practices de Líneas de Productos de software para reducer el riesgo, costo y tiempo de mercadeo mientras mejoran la calidad del producto a traves del reuso sistematico. Las organizaciones que adoptan esto, estan comenzando a requerir el mismo tipo de herramientas que estan hoy disponible para el Desarrollo Rápido de Aplicaciones ó Rapid Application Development (RAD) pero orientado a Lineas de Producto de Software.

Esta sección brinda un sumario de la metodología desarrollada por Microsoft denominada Fábricas de Software (Software Factories). El objetivo de esta metodología es permitir la automatización de tareas del ciclo de vida en el contexto de una Línea de Producción de Software integrando innovaciones en Model-Driven Development (MDD), desarrollo basado en componentes (Component Based Development o CBD), y métodos de desarrollo ágiles. Una Fábrica de Software esta basada en un patrón de cuatro partes para construir patrónes, modelos, frameworks, y herramientas para dominios especificos, como construccion de interface de usuario, diseno de base de datos, o dominios de negocio como salud y seguridad.

Problemas crónicos del desarrollo de software

Hemos identificados cuatro problemas crónicos en los métodos y practicas actuales sobre desarrollo de software que nos impiden aumentar el nivel de automatización (y por ende la capacidad) en el desarrollo de software de software. Cuatro grandes problemas han sobrevivido sin solución desde por lo menos las dos últimas décadas: construcción monolítica; libre generalidad; desarrollo individual; e inmadurez del proceso.

Construcción Monolítica

No hemos sido capaces de implementar el desarrollo por ensamblado a escala commercial significante. El problema no se basa en que hemos fallado en reconocer la oportunidad. El desarrollo por ensamblado ha sido parte de la visión de los pioneros de la industria por decadas, al menos desde el advenimiento de la orientación a objetos, sino antes. Y no se ha debido a falta de inversión en tratar de lograr este objetivo ya que el desarrollo por ensamblado ha sido objetivo de inversions academicas y comerciales en métodos de desarrollo basados en orientación a objetos y componentes. Garlan y otros han sugerido las siguientes razones [GAO95]:

  • Protocolos de comunicaciones muy atados a las tecnologías de implementación de los componentes.

  • Especificaciones de componentes y tecnologías de despliegue muy pobres.

  • Tecnologías de encapsulación que arreglan los límites de componentes en tiempo de desarrollo.

Generalizaciones Libres

Las prácticas y métodos actuales de desarrollo de software generalmente ofrecen mucha más libertad de la que es necesaria para la mayoría de aplicaciones. La mayoría de aplicaciones de negocios, por ejemplo, consisten en unos pocos patrónes basicos. Estos consisten en leer información de una base de datos, la encapsulan en reglas de negocios, la presentan al usuario, dejan que el usuario actue sobre ellas bajo el control de las reglas, y luego escriben los resultados nuevamente en la base de datos. Por supuesto, esto es una sobre simplificación, debido a que las aplicaciones reales de negocios generalmente contienen una variedad de desafíos, como interacciones con sistemas antiguos, grandes cantidades de datos a manejar, gran número de usuarios concurrentes requerimientos específicos de calidad de servicio que hacen que la implementación de estos patrones básicos sea más difícil que lo que parece. Luego de haber desarrollado varias aplicaciones de negocios, podemos decir que mientras siempre existen las particularidades que hacen a cada proyecto único, y detalles que varian, el trabajo a realizar es prácticamente idéntico de proyecto en proyecto.

Desarrollo Individual

No hemos logrado lograr niveles comercialmente significativos de reuso más allá de la tecnología de la plataforma. La causa principal de este problema es que desarrollamos la mayoría de los productos de software individualmente, insolados de otros productos de software. Consideramos a cada producto de software como algo único, a pesar de que la mayoría tienen más similitudes que diferencias entre ellos.

El Retorno de Inversión en el desarrollo de software sería mucho más alto si varias versiones o varios productos fueran tomados en cuenta durante la fase de planeamiento del producto de software.

Consecuentemente, rara vez hacemos inversiones comerciales significantes en identificar, investigar, empaquetar y desplegar activos reusables. El reuso que ocurre es ad-hoc en lugar de ser sistemático. Dada la baja probabilidad que un componente pueda ser reusado en un contexto diferente para el cual fue diseñado, el reuso ad-hoc es casi siempre una contradicción. El reuso rara vez puede ocurrir si explícitamente no se ha planeado el mismo.

Inmadurez de los Procesos

No hemos logrado tampoco desarrollar productos de software en tiempo y dentro del presupuesto de forma consistente, lo que sugiere que los procesos de desarrollo de software son inmaduros. La mayoría se debate entre uno extremo u otro. O son sumamente prescriptivos, priorizando el manejo de complejidad a expensas del manejo de cambios, o bien son sumamente permisivos, invirtiendo la priorización recien mencionada. Un proceso de desarrollo maduro es un prerrequisitos para la automatización,

Innovaciones Críticas

Los problemas económicos y técnicos que impiden una transición de artesanía a manufactura pueden ser superados aplicando las innovaciones criticas dedicadas a atacar la complejidad y el cambio. Todas estas innovaciones existen hoy, y ya han demostrado un notable potencial en productos comerciales, a pesar de que la mayoría todavía no hayan alcanzado un grado de madurez completa. Podemos dividirlas en cuatro áreas: reuso sistemático, desarrollo dirigido por ensamblado, desarrollo dirigido por modelos, y marcos de procesos. Veamos cada una de estas áreas en más detalle.

Reuso sistemático

Una de las innovaciones más importantes en el desarrollo de software es la definición de una familia de productos de software, que integrantes varian, mientras tienen varias prestaciones en comun. Esto posibilita un acercamiento más sistematico al reuso, permitiendonos identificar y diferenciar entre las prestaciones que permanecen más o menos constantes entre varios productos y cuales no lo hacen

Las Líneas de Producto de Software explotan las familias de producto, identificando prestaciones en comun y formas recurrentes de variaciones en dominios especificos para lograr la producción de miembros de la familia de forma más rápida, menos costosa y con menos riesgo. En lugar de conformarse con la inocente esperanza de que las oportunidades de reuso ad-hoc aparezcan solas en situaciones arbitrarias, estas capturan el conocimiento sistematicamente acerca de como producir los miembros de la familia, hacerlos disponibles en forma de Activos reusables, y luego aplicar estos Activos durante la producción de los miembros de la familia. Los Productos desarrollados como miembros de una familia reusan requerimientos, arquitecturas, marcos, componentes, tests y otros tantos activos.

La Figura 1 describe las tareas más relevantes ejecutadas y los artefactos producidos y consumidos en una línea de producto.

Figura 1. Acercamiento a una Línea de Producto

Desarrollo Dirigido por Modelos

Aumentar el nivel de abstracción es uno de los avances claves en el progreso del desarrollo de software. Moverse a niveles más altos de abstracción brinda varios beneficios, incluyendo una mayor productividad, menos defectos, y un mantenimiento y mejora más sencillos. Este es el objetivo del desarrollo dirigido por modelos o model-driven development (MDD). MDD usa modelos para capturar información de alto nivel, usualmente expresada informalmente, y automatiza su implementación, ya sea compilando modelos para producir ejecutables, o usandolos para facilitar el desarrollo manual de ejecutables. Esto es muy valuable ya que esta información suele estar perdida en artefactos de bajo nivel, como archivos de código fuente, donde es muy difícil de seguir, mantener, o mejorar de forma consistente.

Para nuestros propositos lo que nos interesa de MDD son los modelos que pueden ser procesados de la misma manera que actualmente procesamos código fuente. Los modelos usados de esta manera no pueden ser escritos en lenguajes disenados para documentación. Estos deben ser precisos y sin ambiguedades. Tambien, para lograr aumentar el nivel de abstracción, un languaje de modelado debe apuntar a un dominio más especificico que un language de programación de proposito general.

Un lenguaje que cumpla con estos criterios es llamado un language de dominio especifico ó domain-specific language (DSL), porque modela conceptos encontrados en un dominio particular. Un DSL es definido con mucho más rigor que un languaje de programación de proposito general. Como un language de programación, puede tener una notación textual o gráfica.

Dos ejemplos de DSL gráficos se ilustran en la Figura 2, que es una toma gráfica de la pantalla de Microsoft Visual Studio 2005 Team System. El DSL de la izquierda describe componentes, como Web Services. Es usado para automatizar el desarollo de componentes y configuración. El DSL de la derecha describe tipos de servidores lógicos de un centro de datos. Es usado para diseñar e implementar configuraciones de centro de datos. El despliegue de servicios web se logra arrastrando componentes de servicio sobre servidores logicos. Las diferencias entre los recursos que requieren y los recursos disponibles en los servidores lógicos sobre los cuales se van a desplegar son exhibidos como errores de validación, como se ilustra.

Figura 2. Ejemplo de DSL en Visual Studio 2005 Team System

Desarrollo por Ensamblado

Las innovaciones críticas en las areas de protocolos independientes de plataforma, auto descripción, encapsulación variable, ensamblado por orquestración y desarrollo dirigido por arquitectura son requeridos para soportar el desarrollo por ensamblado.

  • Protocolo independiente de la plataforma: Las distintas tecnologías de Web Services (WSDL, SOAP y XML por ejemplo) logran lo que otras anteriores tecnologías de ensamblado de componentes no lograron a partir de separar las tecnologías utilizadas para especificar los componentes de las utilizadas para implementarlos.

  • Autodescripción: La auto descripción reduce el mismatch arquitectonico al mejorar el empaquetado de components y hacer explicitas las assumptions, dependencias, comportamientos, consumo de recursos, performance, y certificaciones.

  • Encapsulación Variable: la encapsulación variable (una adaptación de Programación Orientada a Aspectos o Aspect Oriented Programming –AOP-) reduce las diferencias arquitectonicas al permitir la publicación de componentes parcialmente encapsulados que pueden ser adaptados a nuevos contextos seleccionando e introduciendo los aspectos no-funcionales apropiados con los funcionales.

  • Ensamblado por Orquestración: dados los mecanismos contractuales adecuados, los Servicios pueden ser ensamblados usando un motor de orquestración, como Microsoft BizTalk Server, para manejar la secuencia de mensajes intercambiados entre ellos.

  • Desarrollo Dirigido por Arquitectura: si bien prevenir el ensamblado de componentes mismatched es mejor que construir ensamblados inválidos, esto no promueve necesariamente la disponibilidad de componentes well-matched. Esto es el propósito de la arquitectura, quien reduce el riesgo de mismatch arquitectónico imponiendo assumptions comunes y acotando las decisions de diseño.

Marcos de Proceso

La clave de la maduridad de un proceso es preserver la agilidad mientras aumenta la complejidad creada por el tamano del proyecto, la distribución geografica y el paso del tiempo. La experiencia indica que una cantidad pequena de estructura aumenta la agilidad reduciendo la cantidad de trabajo que a realizar. Este principio puede aplicarse en el contexto de una familia de producto de software para manejar la complejidad sin reducer la agilidad usando marcos de proceso.

Podemos especializar y adaptar un proceso formal para un producto de la familia dado en un marco de proceso bien definido y particular. Un marco de proceso contiene información detallada acerca del proyecto, como configuración de las herramientas, accesos de red, instrucciones para los desarrolladores, documentación de las APIs a ser usadas por el equipo, los nombres de las personas claves en los pasos más importantes del proceso como manejo de la configuración, seguimiento de defectos, políticas de equipo sobre check-in, estilos de codificación y revision por pares, y otros varios detalles especificos al proyecto y al equipo del proyecto.

Una vez que un marco de proceso es definido, micro procesos pueden comenzar a juntarse para soportar cualquier flujo de trabajo que el proyecto requiera, incluyendo top-down, bottom-up, outside-in, testear antes de codificar, codificar antes de testear, en cualquier combinación, o bien un flujo de trabajo totalmente ad-hoc, mientras los imposiciones sean respetados. El flujo de trabajo puede tambien ser ajustado a los recursos permitiendo que el trabajo sea programado para maximizar el rendimiento de procesamiento total usando métodos como PERT y CPM, y también que comiencen cuando los recursos necesarios esten disponibles. Muchos tipos diferentes de recursos pueden influenciar la agenda, incluyendo artefactos como requerimientos y código fuente, personas como desarrolladores o program managers, productos como manejadores de configuraciones o sistema de seguimientos de defectos, y facilities como abrir un puerto o asignar almacenamiento en un servidor. Esto es lo que se denomina planeamiento basado en imposiciones.

Integrando las innovaciones críticas

El acercamiento de fábricas de software integral as innovaciones críticas en un patrón de cuatro partes (conocido como El Patrón de Fábrica de Software) como se sumariza a continuación:

  1. Desarrollo de activos reusables (marcos, patrones, procesos, por ejemplo) con el objetivo de acelerar el desarrollo de productos utilizando una arquitectura bien definida y conocida.

  2. Desarrollo de herramientas de dominio específico para soportar el desarrollo de productos mediante la adaptación, configuración, y ensamblado de componentes basados en marcos.

  3. Uso de herramientas para incentivar la participación de los clientes y responder rápidamente a cambios en los requerimientos mediante la construcción de software incremental, manteniéndolo funcionando mientras los cambios son hechos.

  4. Captura de decisiones de diseño de forma que puedan luego directamente producir ejecutables.

¿Qué es una Fábrica de Software?

Una fábrica de software es una Línea de Producto que configura una herramienta de desarrollo extensible como Microsoft Visual Studio Team System (VSTS) con contenido guía, especialmente pensando para construir tipos específicos de aplicaciones. Una fábrica de software contiene tres ideas claves: un esquema, una plantilla y un ambiente de desarrollo extensible:

  • Imagínese al esquema de una fábrica de software como una receta. Lista los ingredientes, como los proyectos, el código fuente, archivos de SQL y archivos de configuración, y explica como deberían ser estos combinados para crear el producto. Específica cuales DSLs deben ser usados y como los modelos basados en estos DSLs pueden ser transformados en código y otros artefactos, o en otros modelos. Describe la arquitectura de la línea de producto, y las relaciones claves entre componentes y marcos de los que se compone.

  • La plantilla de una fábrica de software es como una bolsa de groceries conteniendo los ingredientes listados en la receta. Provee los patrones, guía, plantillas, marcos, ejemplos, herramientas a medida como por ejemplo DSLs, y otros ingredientes usados para construir el producto.

  • Un entorno de desarrollo extensible como VSTS es como la “cocina” donde se cocina la comida. Una vez que es configurado con una plantilla para fábrica de software, VSTS se convierte en una fábrica de software de una familia de producto determinada.

Para llevar esta analogía aún más lejos, podemos decir que los productos son como las comidas servidas por un restaurante. Los Interesados de las fábricas de software son como los clientes que ordenan una comida del menú. La especificación de un producto es como una orden de producto específica. Los desarrolladores del producto serían los cocineros que preparan las comidas descriptas por las ordenes de comida, y quienes pueden modificar la definición de las comidas, o bien preparar comidas que no estén en el menú. Y los desarrolladores de la línea de producto serían los chefs que deciden que va a aparecer en el menú, y los ingredientes, procesos, y equipamientos de cocina que serán usados para prepararlos.

Realizando la visión de Fábricas de Software

Las Fábricas de Software están basadas en la convergencia de ideas claves en reuso sistemático, MDD, desarrollo por ensamblado, y marcos de proceso. Varias de estas ideas no son nuevas. Lo nuevo es la síntesis de las mismas en un enfoque que permite a las organizaciones con experiencia en dominios implementar el patrón de Fábrica de Software, construcción de lenguajes, patrones, marcos y herramientas para automatizar el desarrollo en dominios específicos.

Pensamos que piezas claves de la visión de Fábrica de Software van a lograrse rápidamente, mientras que otras llegaran en los próximos años. Herramientas comerciales que pueden albergar Fábricas de Software, como Microsoft Visual Studio .NET y IBM WebSphere Studio, están disponibles hoy. La tecnología DSL es mucho más nueva que la mayoría del resto de las tecnologías, y esta basada en familias de lenguajes extensibles. Sin embargo el desarrollo de herramientas y marcos de DSL están actualmente bajo desarrollo (ver website Microsoft Visual Studio 2005 DSL Tools) , sin embargo ya están comenzando a aparecer de forma comercial.

Visión sobre la fábrica de software para HL7

Esta sección esta dedicada a la vision de fábrica de software HL7 como fue previamente descripta:

Desarrollar una Fábrica de Software que simplifique a los proveedores de soluciones médicas la arquitectura, diseño e implementación de aplicaciones compatibles con la version 3 de HL7 dentro de un ambiente de servicios web construido utilizando herramientas de Microsoft y components de la plataforma .Net.

Las siguientes preguntas serán respondidas durante la elaboración de la visión:

Tabla 1

Pregunta

Sección

¿Qué activos se pueden usar para el desarrollo autosuficiente de las fábricas?

0

¿Que imposiciones existen en el ambiente de producción?

0

¿Que imposiciones existen en el ambiente de desarrollo?

0

¿Quienes son los Interesados de la fábrica?

0

¿Como va a encajar la fábrica dentro del proceso de desarrollo?

0

¿Como van a encajar los productos desarrollados usando la fábrica en el ambiente de producción?

0

¿Que problemas esta tratando de resolver la fábrica?

0

¿Que soluciones trata de ofrecer la fábrica?

0

¿Como es la arquitectura de software de la fábrica?

0

¿Como es el proceso de desarrollo?

0

¿Que herramientas van a proveerse con la fábrica para automizar el desarrollo?

0

¿Como es el esquema de la fábrica?

0

Panorama

La fábrica de software HL7 tiene como objetivo resolver los problemas encontrados dentro del contexto de negocios de la industria médica. Inicialmente, la fábrica esta definida en el contexto de dos negocios principales que incluyen:

  • Manejo de Laboratorio: incluye el problema de integración del laboratorio clínico dentro de la empresa de salud.

  • Reporte de la Salud Pública: incluye el problema del reporte de eventos relacionados con la seguridad en la empresa de salud.

La solución de la fábrica es permitir:

Que las aplicaciones utilicen colaboraciones de HL7 v3 (por ej.: una serie de interacciones de HL7) que colectivamente soporten una meta de negocios (por ej.: completar una observación de laboratorio).

Que las aplicaciones se comuniquen utilizando una infraestructura de servicios web basada en estándares y compatible con el HL7 v3 Web Service Profile.

La solución de la fábrica también asume lo siguiente:

  • Las aplicaciones no fueron disenadas para HL7 v3.

  • Las aplicaciones no fueron disenadas para colaborar.

  • Las aplicaciones no fueron disenadas para comunicarse sobre una infraestructura de servicios web.

Como va a ser demostrado en las proximas secciones, los Puertos de Colaboración HL7 son los “productos finales” producidos por la fábrica.

Activos existentes

Uno de los primeros pasos al definir una fábrica de software es evaluar los Activos existentes (estilos de arquitectura, estándares de dominios específicos, plataformas, etc) que pueden ser aprovechados para lanzar la fábrica.

En el caso de la fábrica de HL7, varias categorías de activos existentes pueden ser utilizados en este proceso de lanzamiento. Estos incluyen:

Tabla 2

Categoría

Descripción

Activos de Sistemas de Información de Salud

Activos especificos al desarrollo e interopera bilidad de los sistemas de información de salud. Por ejemplo, los siguientes artefactos de HL7 y IHE son considerados Activos dentro de esta categoría:

  • HL7 Version 3 Ballot Publication

  • HL7 Version 3 Marco desarrollo de mensajes

  • HL7 Herramientas y Repositorio

  • HL7 Formato de intercambio de modelos

  • HL7 Modelos de casos de usuarios

  • HL7 Modelos de información

  • HL7 Modelos de interacción

  • HL7 Definición de mensajes jerarquicos

  • HL7 Especificaciones de implementación de tecnología

  • HL7 Web Service Profiles

  • IHE Marco ténico para laboratorios

Activos de arquitectura

Activos que pueden ser usados para facilitar la definición del software y arquitectura de la fábrica. Por ejemplo, la arquitectura de Microsoft's BizTalk Server 2004 ha influido de forma importante la arquitectura de la fá brica como es detallado en la Sección 0.

Activos de implementación

Activos que pueden ser utilizados para soportar la implementación de artefactos producidos por la fábrica. Mayormente, esto se refiere a las implementaciones de referencia de aplicaciones compatibles con HL7 v3.

Activos de desarrollo de la fábrica

Activos que pueden ser utilizados para construir la fábrica misma. Por ejemplo, el Microsoft Domain Specific Language (DSL) SDK puede ser usado para desarrollar el DSL de Puertos de Colaboración HL7 como se muestra en la Sección 0.

Activos de plataforma

Activos (por ej.: componentes en tiempo de ejecución) que son parte de una solución desplegada de HL7. Por ejemplo, el marco Microsoft .Net y el marco de Mejoras para Servicios Web para Microsoft .Net pueden ser usados como la plataforma de Servicios Web de la fábrica.

Imposiciones

Cuando se define una fábrica, es importante diferenciar las imposiciones de los productos desarrollados utilizando la misma de las imposiciones de la fábrica misma. Estas incluyen:

Imposiciones de la Aplicación: requerimientos impuestos en la aplicación desarrollado utilizando la fábrica como estandares, interfaces externas, o requerimientos administrativos de localización, empaquetado, licenciamiento e instalación.

Imposiciones de la Fábrica: requerimientos impuestos por la fábrica en el proceso de desarrollo de la aplicación como preferencias de tecnología, proveedores o plataforma, criterios de aceptación y reportes, imposiciones de presupuesto y de agenda, o politícas de desarrollado y ayuda.

Como ejemplo, las siguentes constants son asumidas por la fábrica de software de HL7:

Tabla 3

Tipo

Nombre

Descripción

Imposiciones de Aplicación

HL7 Application Role Conformance

Para adherer al standard HL7 v3, las aplicaciones HL7 deben ser compatibles con los roles de aplicación designados por HL7. Para esto el software debe: 1) enviar todos los mensajes que sean requeridos por un rol de aplicación, 2) recibir todos los mensajes que sean requeridos por un rol de aplicación, 3) implementar responsabilidades del rol de aplicación destinatario.

Imposiciones de Aplicación

HL7 Web Service Profile Conformance

Las aplicaciones desarrolladas usando la fábrica deben ser compatibles co Servicios Web:

  • HL7 Web Services Basic Profile

  • HL7 Web Services Addressing Profile (optional constraint)

  • HL7 Web Services Reliable Messaging Profile (optional constraint)

  • HL7 Web Services Security Profile (optional constraint)

Limitación de la Fábrica

Tecnologías de desarrollo y plataforma

El desarrollo de aplicacions HL7 usará las siguientes tecnologias de desarrollo y plataforma de Microsoft:

  • Microsoft Visual Studio 2005 Team System

  • Web Services Enhancements for Microsoft .Net version 2.0

  • Microsoft .Net Framework

  • Microsoft BizTalk Server 2004

  • Microsoft SQL Server

  • Microsoft Active Directory

  • Microsoft Windows Server Platform

Interesados

Varios Interesados son claves en el suceso de la fábrica de software HL7. Esto incluye a:

  • Proveedores de Salud: estos son los usuarios finales de las aplicaciones desarrolladas con la fábrica

  • Proveedores de Soluciones: usuarios de la fábrica que produce aplicaciones compatibles con HL7

  • Arquitectos y desarrolladores de la fábrica: especifica la fábrica e implementa Activos para la misma.

  • Comite de Herramientas HL7: especifica las herramientas usadas por la comunidad HL7 para implementar aplicaciones compatibles con HL7.

Contexto

Es importante entender el contexto de una fábrica de software desde dos perspectivas:

  • Contexto de Producción: Especifica donde, en producción, residen los productos finales producidos por la fábrica.

  • Context o de Desarrollo: Especifica donde se ubica la fábrica de software dentro del ambiente general de desarrollo.

Contexto de Producción

En el caso de la fábrica de software HL7, los Puetros de Colaboracion HL7, son los productos finales. La Figura 3 lista el contexto de produccion de los Puertos de production context for HL7 Collaboration Ports en relación a las aplicaciones HL7. En este escenario, un puerto de colaboración para el Sistema de Información Hospitalario es el producto final producido por la fábrica. Mas detalle sobre los Puertos de Colaboración HL7 es provisto in la sección 0.

Figura 3. HL7 Contexto de Puertos de Colaboración

Contexto de Desarrollo

Figura 4 muestra el contexto general de la fábrica en terminos del proceso de desarrollo de la fábrica HL7 y los puertos de colaboración HL7

Figura 4. Contexto de la Fábrica de Software HL7

El Problema

Antes de embarcarnos en buscar una solución específica, el enfoque de fábrica de software se focaliza en definir el dominio del problema. Esto incluye definir los problemas que deben ser solucionados por la fábrica ademas de modelar estos problemas usando un modelo de prestaciones de problemas. Este modelo ofrece un medio para modelar los elementos comunes y variables dentro de un dominio particular y es utilizado como fuente de información de configuración (ver [CE00] para más información sobre modelo de prestaciones).

Problemas Prototípicos

La fábrica de software HL7 esta destinada a resolver problemas encontrados dentro del contexto de negocios de una empresa de salud. Como mencionamos antes, inicialmente, la fábrica es definida en el contexto de dos dominios de negocios principales:

  • Manejo de Laboratorio: abarca el problema de integrar el laboratorio clínico dentro de la empresa de salud.

  • Reporte de Salud Pública: abarca el problema de reportar eventos relacionados con la seguridad dentro de la empresa de salud.

La próxima tabla incluye un ejemplo (reducido) de la lista de problemas prototípicos a ser resueltos por la fábrica para estos dominios. Cada problema (Pñ) esta alineado con los encontrados por Interesados de negocios específicos y son luego mapeados a un set de problemas característicos.

Interesados: H = Proveedores de Salud, L = Laboratorios, P = Salud Pública y Agencias Regulatorias, M = Fabricantes

Features: OP = Petición de Ordenes, OT = Seguimiento de Ordenes, OF = Cumplimiento de Ordenes, WM = Manejo del Trabajo, HER = Reporte de Eventos de Salud, PIM = Manejo de la Información del Paciente

Tabla 4

Es importante notar que la noción de HL7 v3 es considerada parte del dominio de solución definido en la Sección 0. Mantener a HL7 fuera del dominio del problema permite que el mismo permanezca independiente de cambios al estándar de HL7.

Modelo de Prestaciones del Problema

Figura 5 representa una porción del modelo de prestaciones del problema (solo el dominio del Manejo de Laboratorio es ilustrado) de la fábrica de software HL7

Figura 5. Modelo de Prestaciones de Problema (Porción)

La Solución

En el enfoque de fábrica de software, el dominio de solución incluye identificar las soluciones (al dominio del problema) que deben ser provistas por la fábrica además de modelar estas soluciones en un modelo de prestaciones de solución.

Definición del Dominio de Solución

El principal intento de la solución de fábrica de software HL7 esta resumido por la siguiente declaración de problema (desde una perspectiva de solución):

Declaración del Problema: Permitir a las aplicaciones de salud colaborar entre ellas utilizando interacciones definidas por HL7 sobre una infraestructura de Servicios Web.

Esto es, la fábrica proveerá una solución que permita:

  • Que las aplicaciones implementen colaboraciones HL7 v3 que colectivamente soporten una meta de negocios (por ejemplo, completar una orden de laboratorio).

  • Que las aplicaciones se comuniquen utilizando una infraestructura de servicios web basada en estandares abiertos y compatibles con HL7 V3 Web Service Profiles (estas son imposiciones de aplicación).

La solución de la fábrica asume lo siguiente:

  • Las aplicaciones no fueron diseñadas para HL7 v3.

  • Las aplicaciones no fueron diseñadas para colaborar

  • Las aplicaciones no fueron diseñadas para comunicarse a traves de una infraestructura de servicios web.

Desde una perspectiva de alto nivel, la fábrica va a posibilitar a aplicaciones diferentes el intercambio de mensajes compatibles con HL7 v3 como se muestra en Figura 6.

Figura 6. El Modelo de Colaboración HL7

Más específicamente, la fábrica permitirá colaboraciones entre roles de aplicación HL7 (implementados por sistemas de aplicación, como por ejemplo, Sistema de Ordenes, Sistema de Laboratorio, Sistema de Reporte de Resultados) como los representados en la Figura 7.

Figura 7

Este diagrama de sencuencia muestra interacciones entre roles de aplicación HL7 y el tiempo relative de cada interacción HL7 en relación a otras interacciones

Lista del Prototipo de Solución

La próxima tabla incluye un ejemplo (reducido) de la lista de solución prototípica a ser encarada por la fábrica. En este caso, “solución” es sinónimo de “requerimiento” (en otras palabras, estos requerimientos proven soluciones a los problemas identificados en la Sección 0 ademas de tomar en cuenta imposiciones como se menciona en la Sección 0. Más adelante, cada requerimiento (Rñ) es mapeado a un set de prestaciones de solución.

Prestaciones: HL7 = Modelos de Interacción de HL7, WS = Servicios Web básicos, WSS = Seguridad de Servicios Web, WSR = Mensajería confiable en servicios web, AI = Integración de aplicaciones (que no sean Servicios Web), OR = Orquestación, ADM = Administración.

Tabla 5

Modelo de Prestaciones de Solución

El solution feature model de la fábrica de software HL7 es bastante extenso y solo porciones reducidas serán provistas aquí.

Por ejemplo, Figura 8 modela el set de interacciones y roles de aplicación dentro del dominio de Laboratorio de HL7 v3 en el modelo de prestaciones de solución. Un mapeo debe definirse entre problem domain features y estas solucio domain features de HL7

Figura 8. HL7 Domain Feature Model de Laboratorio

Desde que una de los primeros objetivos de la fábrica de software HL7 es permitir interaciones definidas en HL7 v3 sobre una infraestructura de servicios web, prestaciones no-funcionales relacionadas con la interacción de servicios web es también importante en Figura 9. Esta porción del modelo de prestaciones incluye prestaciones obligatorias y prestaciones opcionales para comunicación básica entre aplicaciones sobre una infraestructura de Servicios Web.

Figura 9. Prestaciones básicas de Servicios Web, Direccionamiento y Mensajería Segura.

La Arquitectura

Además del entendimiento de los problemas a ser solucionados por la fábrica y prestaciones del dominio de solución, un activo clave establecido como parte de la fábrica de software es su arquitectura de software (una descripción más completa debería incluir la arquitectura técnica también). Esta define los componentes y las interacciones soportados entre estos componentes y ofrece el marco total sobre el cual las aplicaciones son desarrolladas y entregadas.

Como se indico anteriormente, los Puertos de Colaboracion HL7 son los “productos finales” producidos por la fábrica. Una vista de alto nivel de la arquitectura de estos Puertos de Colabración se detalla en la Figura 10.

Figura 10. Arquitectura de los Puertos de Colaboración de HL7

El flujo de mensajes de alto nivel (numerados en la Figura 10) a traves de los Puertos de Colaboración HL7 se da de la siguiente manera:

  1. System A (por ejemplo, Sistema de Información Hospitalaria) determina que un mensaje debe ser enviado al System B (por ejemplo, Sistema de Información de Laboratorio). System A coloca el mensaje a enviar en una cola de mensajes y notifica el Collaboration Port Adaptor (Receiver) para que envie el mensaje al destino especificado (System B).

  2. El Collaboration Port Adaptor (Sender) recoje el mensaje de la cola de mensajes y lo pasa al Message Receiver.

  3. El Message Receiver pide al Message Filter (Receiver) que coloque el mensaje dentro de la estructura interna de mensaje del Puerto de Colaboración.

  4. El Message Receiver luego notifica al Message Dispatcher sobre el recibo del mensaje.

  5. El Message Dispatcher reenvia el mensaje al Message Sender que ha sido previamente registrado ante el Message Dispatcher para recibir mensajes de este tipo. Opcionalmente (indicado por el número 5* en el diagrama), el Orchestration Manager puede haberse registrado para recibir el mensaje para procesamiento de orquestración.

  6. El Message Sender pide al Message Filter (Sender) que procese el mensaje saliente. En este caso, el mensaje es traducido a una fuente XML.

  7. El Message Sender luego reenvia esta fuente XML al Collaboration Port Adaptor (Sender).

  8. El Collaboration Port Adaptor (Sender) empaqueta la fuente XML en un pedido de SOAP y lo envia al sistema destino (System B).

El proceso de desarrollo de aplicaciones y las herramientas utilizadas

El enfoque de fábrica de software no solo especifica activos reusables en forma de componentes y marcos, sino que tambien define un proceso de desarrollo de aplicaciones a ser utilizado por los consumidores de la fábrica y un conjunto de herramientas para facilitar la automatización dentro de la fábrica.

El Proceso

La Figura 11 ofrece una vista de alto nivel del marco de proceso de desarrollo de aplicaciones definido por la fábrica de software HL7 (las líneas punteadas indican ciclos de retroalimentación). El proceso comprende un modelo de proceso de desarrollo iterativo para proveer retroalimentación continua y resultados más inmediatos.

Figura 11. Flujo del Proceso de Desarrollo de Puertos de Colaboración HL7

Las Herramientas

La siguiente tabla lista varias de las herramientas que se necesitarán para soportar el desarrollo dentro de la fábrica de software HL7.

Tabla 6

Herramienta

Descripción

Herramienta Microsoft

Diseñador de Puertos de Colaboración HL7

Provee un medio para desarrollar un modelo visual y metadata correspondiente de Puertos de Colaboración HL7. Un ejemplo de un modelo visual producido por este diseñador puede encontrarse en la Sección 4

Microsoft VSTS 2005 (extension al Diseñador de Aplicaciones)

Microsoft DSL Tools

.

.

Generador de código de Puertos de Colaboración HL7

Provee la generación de código fuente (en C#) y de artefactos de proyecto adicionales (WSDL, por ejemplo) a partir de la metadata producida por el diseñador de Puertos de Colaboración HL7.

Microsoft VSTS 2005

Microsoft DSL Tools

Microsoft Recipe Framework

Diseñador de Sistemas Lógicos

Facilita el desarrollo de modelos visuals y metadata correspondiente para la arquitectura técnica de los Puertos de Colaboración HL7. Un ejemplo de modelo visual producido por este diseñador puede encontrarse en la Sección 4.

Microsoft VSTS 2005 (Diseñador de Sistemas Lógicos)

Diseñador de Orquestración

Facilita el desarrollo de modelos visuales y metadata correspondiente para la orquestración del flujo de mensajes entre los componentes de la aplicación

Microsoft BizTalk 2004 Diseñador de Orquestración

Ambiente Integrado de Desarrollo

Provee un ambiente común para todas las herramientas de desarrollo (compiladores y diseñadores visuals) y actividades realizadas por los desarrolladores de Puertos de Colaboración HL7

Microsoft VSTS 2005

Constructor de Soluciones

Provee los mecanismos para configurar la plantilla de una fábrica de software HL7 dentro del ambiente de desarrollo VSTS 2005. Esto incluye configurar los modelos de prestaciones de problemas y soluciones y generar soluciones, proyectos y artefactos inciales de Visual Studio (por ejemplo, modelos).

Microsoft VSTS 2005

Microsoft Recipe Framework

Diseñador de Clases

Facilita el desarrollo de un modelo visual y correspondiente metadata de un conjunto de clases dentro del ambiente VSTS 2005 proveyendo generación de código ademas de sincronización automática entre el modelo y el código.

Microsoft VSTS 2005 (Diseñador de Clases)

El esquema de una fábrica de software

Como mencionamos anteriormente, el esquema de una fábrica de software puede ser visto como una receta. Lista ingredientes, como los proyectos, archivos de código fuente, de SQL, de configuración y explica como estos deben ser combinados para formar un producto. Detalla que DSLs pueden ser usados y describe como los modelos basados en estos DSLs pueden ser transformados en código fuente y otros artefactos, o, en otros modelos. Describe la arquitectura de la línea de producto, y las relaciones claves entre los componentes y marcos que la componen.

La Figura 12 gráfica el esquema de fábrica de software de HL7, mostrando los: viewpoints, contenidos de los viewpoints (herramientas, activos y artefactos producidos), y relaciones entre los viewpoints.

Figura 12. Esquema de fábrica de software HL7 (click para agrandar imagen)

La fábrica de software de HL7 como ejemplo

Esta sección incluye un ejemplo detallado de una pequeña porción de la fábrica de software HL7 presentada en este artículo.

Por favor note que, a pesar de que las imagenes abajo muestran como una fábrica de software puede ser construida y albergada dentro de la plataforma de desarrollo Microsoft Visual Studio 2005, estas no forman parte de un producto específico de Microsoft y son provistas únicamente a modo ilustrativo.

Configurando La Solución

Luego de configurar el dominio del problema (no mostrado aquí), el próximo paso consiste en terminar de configurar el modelo de prestaciones de la solución como se muestra en la Figura 13. La idea es que el modelo de prestaciones de la solución esta pre-configurado (por ejemplo, algunas interacciones y roles de aplicación de HL7 son seleccionados como parte de la solución) en base a la configuración del modelo de prestaciones del problema.

Figura 13. Configurando la Solución

El panel izquierdo permite al usuario de la fábrica seleccionar que prestaciones incluir en la solución como parte de la instanciación de la fábrica. El panel del medio muestra la misma información visualizada en el panel anterior utilizando una notación gráfica en lugar de texto. El panel de la derecha muestra la vista estándar del Explorador de Solución de Microsoft Visual Studio 2005.

Modelando y Configurando La Solución

El próximo paso consiste en utilizar el Diseñador de Puertos de Colaboración de HL7 (una herramienta basada en DSL) para modelar y configurar el contexto del puerto de colaboración. Nuevamente, la idea es que un modelo de puerto de colaboración incial sea creado en base a la configuración del modelo de prestaciones de la solución (ver paso anterior). Este modelo especifica el puerto de colaboración, interfaces a sistemas externos y los adaptadores utilizados para comunicar mensajes entre sistemas.

Figura 14. Modelando y Configurando la Solución

El panel del medio muestra el modelo visual para un puerto de colaboración determinado y permite al usuario manipular gráficamente la topología de un puerto de colaboración y de su ambiente. El panel izquierdo permite al usuario de la fábrica configurar el elemento del modelo seleccionado. En este caso el usuario esta configurando un “Web Service Requestor” (seleccionado en el panel del medio). Por ultimo, el panel derecho, muestra la vista estándar del Explorador de Soluciones de Visual Studio 2005

Generando Implementaciones

El próximo paso es usar el Diseñador de Puertos de Colaboración de HL7 (una herramienta basada en DSL) para implementar parte de la solución para el puerto de colaboración. Este paso involucra un generador de código especializado para HL7 (el HL7 Collaboration Port Code Generator) que interpreta la configuración del modelo, lo relaciona con plantillas de código pre-establecidas y genera código fuente para que ser compilado.

Figura 15. Generando Implementaciones

En este caso, el usuario selecciona la opción “Implement” del menú contextual del modelo visual del panel del medio. El resto de los paneles ya fueron descriptos en la sección anterior

Modelando y Configurando el Ambiente de Despliegue

El próximo paso consiste en utilizar el Diseñador de Sistemas Lógicos para modelar y configurar el ambiente de despliegue de los Puertos de Colaboración HL7.

Figura 16. Modelando y Configurando el Ambiente de Despliegue

El panel izquierdo muestra un conjunto de elementos de modelado que pueden ser ubicados en el diagrama gráfico del panel del medio. El panel derecho sigue mostrando el Explorador de Soluciones de Visual Studio 2005

Referencias

[BEE04]G. W. Beeler. Documentation of HL7 Internal Tooling Structure, Metadata, and Semantics, Release 1. HL7 Methodology & Modeling Committee. May 2004.
[BPT]Blueprint Technologies, Inc.
[BOS00]J. Bosch. Design and Use of Software Architectures: Adopting and evolving a product-line approach. Addison-Wesley. 2000.
[CE00]K. Czarnecki, U. W. Eisenecker. Generative Programming: Methods, Tools and Applications. Addison-Wesley. 2000.
[CIS04]Data Center Networking: Internet Edge Design Architectures. http://www.cisco.com/application/pdf/en/us/guest/netsol/ns304/c649/ccmigration_09186a008014ee4e.pdf. Cisco Systems, Inc. 2003.
[GAO95]D. Garlan, R. Allen, J. Ockerbloom. Architectural Mismatch: Why Reuse Is So Hard. IEEE Software 12, 6, 1995.
[GLO04]H. Glover, BSc, PhD. HL7 V3—UK Implementation Progress. http://www.hl7.de/iamcda2004/finalmat/day2/UK%20Progress%20HG.pdf. International Meeting, Acapulco, October 19th 2004.
[GR+J04]J. Greenfield. Case for Software Factories. http://msdn.microsoft.com/architecture/overview/softwarefactories/default.aspx?pull=/library/en-us/dnmaj/html/aj3softfac.asp. July 2004.
[GR+A04]J. Greenfield. Software Factories: Problems and Innovations. http://msdn.microsoft.com/architecture/overview/softwarefactories/default.aspx?pull=/library/en-us/dnbda/html/softwarefactwo.asp%23softwarefactwo_topic3. August 2004.
[GS04]J. Greenfield and K. Short with S. Cook and S. Kent. Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools. Wiley. 2004.
[GS+SD04]J. Greenfield and K. Short. Moving to Software Factories. http://www.softwarefactories.com/ScreenShots/MS-WP-04.pdf. Software Development Magazine, July 2004.
[HIN03]A. Hinchley. Understanding Version 3: A primer on HL7 Version 3 Communication Standard. Alexandar Monch Publishing. 2003.
[HL7V304]HL7 V3 Ballot Publication. Health Level Seven, Inc. 2004
[IHEL104]IHE Laboratory Technical Framework: Volume 1 Integration Profiles. Integrating the Healthcare Enterprise. 2004.
[IHEL204]IHE Laboratory Technical Framework: Volume 2 Transactions. Integrating the Healthcare Enterprise. 2004.
[MDF99]HL7 Modeling and Methodology Committee. Message Development Framework Version 3.3. http://www.hl7.org/Library/mdf99/mdf99.pdf. Health Level Seven, Inc. December 1999.
[ONA03]A. Onabajo. et. al. Wrapping Legacy Medical Systems for Integrated Health Network. Department of Computer Science, University of Victoria. 2003.
[TATA04]HL7 Web Services Profile Reference Implementation Guide Version 1.0. Tata Consultancy Services. 2004.
[TM03]D. Trowbridge, D. Mancini, D. Quick, G. Hohpe, J. Newkirk and D. Lavigne. Enterprise Solution Patterns Using Microsoft .Net: Version 2.0. Microsoft. 2003.
[WSA04]W3C Web Service Addressing (WS-Addressing). http://www.w3.org/TR/2004/WD-ws-addr-core-20041208/ . World Wide Web Consortium (W3C) Working Draft. December 2004.
[WSB04]WS-I Basic Profile Version 1.0. http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html . Web Services Interoperability Organization (WS-I). 2004.
[WSPA04]R. Ruggeri, et. al. HL7 Web Services Basic Profile. Health Level Seven, Inc. 2004.
[WSPB04]R. Ruggeri, et. al. HL7 Web Services Addressing Profile. Health Level Seven, Inc. 2004.
[WSPR04]R. Ruggeri, et. al. HL7 Reliable Messaging Web Services Profile. Health Level Seven, Inc. 2004.
[WSPS04]R. Ruggeri, et. al. HL7 Web Services Security Profile. Health Level Seven, Inc. 2004.
[WSR04]Web Services Reliable Messaging Protocol (WS-ReliableMessaging). http://msdn.microsoft.com/webservices/understanding/specs/default.aspx?pull=/library/en-us/dnglobspec/html/ws-reliablemessaging.asp. BEA Systems Inc., International Business Machines Corporation, Microsoft Corporation, Inc, and TIBCO Software Inc. 2004.
[WSS04]Web Services Security: SOAP Message Security 1.0. http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf. Organization for the Advancement of Structured Information Standards (OASIS). 2004.

Mostrar: