UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA INGENIERÍA PROYECTO FIN DE CARRERA

Transcripción

1 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA INGENIERÍA EN INFORMÁTICA PROYECTO FIN DE CARRERA I8K: Arquitectura de Servicios para la Gestión de la Calidad de los Datos: Una implementación de ISO 8000: Isabel Bermejo Manzaneque Junio, 2013

2

3 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA DEPTO. DE TECNOLOGÍAS Y SISTEMAS DE INFORMACIÓN PROYECTO FIN DE CARRERA I8K: Arquitectura de Servicios para la Gestión de la Calidad de los Datos: Una implementación de ISO 8000: Autor: Isabel Bermejo Manzaneque Directora: Mª Luisa Parody Núñez Tutor: Ismael Caballero Muñoz-Reja Junio, 2013

4

5 TRIBUNAL: Presidente: Vocal : Secretario: FECHA DE DEFENSA: CALIFICACIÓN: PRESIDENTE VOCAL SECRETARIO Fdo.: Fdo.: Fdo.:

6

7 Resumen Hoy en día, uno de los activos más importantes que poseen las organizaciones, son los datos. Estos datos son críticos para las organizaciones y conforman la base para sus procesos de negocio. Por tanto, si las organizaciones no utilizan estos datos o si los datos no tienen un nivel adecuado de calidad, harán que las operaciones y procesos de toma de decisiones fracasen o no consigan sus objetivos. En muchas ocasiones, cuando dos o más organizaciones interactúan, es necesario que intercambien datos entre ellas. Estos intercambios pueden producir que datos defectuosos se propaguen entre organizaciones, produciendo que los problemas en la toma de desciciones se agraven. Para paliar o mitigar los problemas que se pudieran generar con los intercambios de datos, se hace necesario algún tipo de mecanismo. La Gestión de Datos Maestros permite abordar estos problemas rigiendo la calidad de los datos, su uso y sincronización en los intercambios. La familia de estándares ISO/IEC 8000: describe los aspectos específicos de Datos Maestros para gestionarlos en sistemas de información. En este Proyecto Fin de Carrera se realiza una implementación del estándar como parte de la Gestión de Datos Maestros y Calidad de Datos. Para ello se ha diseñado e implementado una Arquitectura de Servicios, llamada I8K, que lleva a cabo el proceso de evaluación y certificación de Calidad de los Datos en los intercambios de éstos; y un Interfaz de Programación de Aplicaciones, llamada ICS-API, que hace posible la comunicación con dicha arquitectura. Como ejemplo de aplicación se ha utilizado una aplicación, llamada TripPlanner que consiste en un organizador de viajes. vii

8

9 Abstract Nowadays, data can be considered as one of the most important assets that organizations have. The importance is grounded on the fact that data is used as basis for making decisions and as the raw material for the business processes. If data has not the adequate levels of Quality for the intended use at the tasks at hand, business operations will not succeed, and consequently, organization can fail in the aims to achieve their business goals. Often, organizations need to interact in order to share and exchange data to perform a business. As part of the Exchange of data, some defective data can be propagated between organizations, making problems due to low data Quality in the target organization become even worse. In order to alleviate these kind of problems, some mechanisms are necessary. Techniques of Master Data Management can be used to face up with this kind of problems, since they can address data quality, usage, and data synchronization concerns. ISO/IEC 8000: family of standard describe some specific features about Master Data in order to be managed by an Information System. As a result of the work presented in this technical report, reader can find the steps of the development and the corresponding resulting products necessary to make the family of standard related to MDM operative. Two main products have been developed: I8K, which is a Service Architecture to support the processes of assessment and certification of the level of data quality; and a Application Programming Interface called ICS-API, to make easier existing applications to communicate to I8K in order to consume the services it offers. These two products have been tested by means of an existing software application called TripPlanner, which need to consume high-quality volume of data. ix

10

11 A mi madre y a mi padre. Porque sin ellos esto no hubiera sido posible. A mis hermanas. Por su apoyo incondicional. A Emilio. Por saber estar ahí siempre. A Almudena. Por sus ánimos, apoyo y dedicación en estos años de carrera. xi

12

13 Agradecimientos A lo largo de mi vida, son muchas las personas que me he encontrado en mi camino, cada una de ellas responsable de buenos y malos momentos que han hecho posible que hoy sea quien soy. En este proyecto quiero agredercer en especial a las personas que han estado conmigo en estos últimos años. A Ismael Caballero y a Luisa Parody, por el tiempo dedicado a sacar adelante este proyecto, por su a apoyo, dedicación, ideas y consejos, no solo en el ámbito académico sino en lo personal. A Ismael por confiar siempre en que era capaz de realizarlo; y a Luisa por tener siempre una dosis de optimismo. A Concha de la Torre, Sonia Mª González y Almudena Buitrago por hacer los años de la carrera mucho más sencillos y haber hecho posibles muchos buenos ratos. En especial a Almudena por haber estado este largo camino siempre apoyándome y enseñarme que todo es posible. A los integrantes del grupo de prácticas de ISO2, por hacer que el desarrollo de una práctica fuera mucho más que eso. A los integrantes del grupo de investigación Alarcos, por el buen ambiente de trabajo. A Elena Fernández, Beatriz Moraleda, Rocío Buitrago y Cristina Bermejo, por ofrecerme estos buenos años de convivencia y aguantar mi estrés. A mis amigas de Campo de Criptana, por su compañía, por su saber estar y por su apoyo en todo momento. A Emilio, por su apoyo, por su compresión y por sacar el lado bueno de las cosas en todo momento. A mi familia por recibir siempre el mejor apoyo y hacer posible la persona que soy hoy. xiii

14

15 Índice general Índice de figuras Índice de tablas Índice de listados xvii xviii xix 1 Introducción Dominio del problema y naturaleza de la solución propuesta Contextualización del proyecto Estructura del documento Objetivos del PFC Objetivo Principal Objetivos parciales o específicos Estado del Arte Calidad de datos y Gestión de Datos Maestros Concepto de calidad de datos Datos Maestros y Gestión de Datos Maestros Familia de estándares ISO/IEC: Ejemplo de aplicación: TripPlanner Aspectos tecnológicos XML y JAXB SOA y Servicios Web Método de Trabajo Breve Descripción de PUD Fases del desarrollo basado en PUD Marco tecnológico de trabajo Herramientas para la Gestión de Proyectos Herramientas para el modelado de software y la elaboración de la memoria Herramientas y tecnologías para el desarrollo del proyecto Aplicación del PUD a este PFC Resultados Fase de Inicio Captura e identificación requisitos Modelo de Casos de Uso para cada Sistema xv

16 xvi ÍNDICE GENERAL Plan de iteraciones Fase de Elaboración Iteración Iteración Iteración Fase de construcción Iteración Iteración Iteración Iteración Iteración Fase de transición Iteración Iteración Iteración Conclusiones y Propuestas Objetivos logrados Conclusiones Propuestas de trabajos futuros Publicaciones Opinión personal Bibliografía 108 A Modelo de Datos Maestros para el dominio de la aplicación TripPlanner 113 B Esquema XML del formato de los Mensaje de Datos Maestros. Versión C Esquema XML del formato de los Mensaje de Datos Maestros. Versión D Código de los casos de prueba 131 E Ejemplo de traza del TripPlanner* y el proveedor FlightSA 137 F Manual de Usuario 151 F.1 Aplicación del tipo AP F.1.1 Codificar un Mensaje de Datos Maestros F.1.2 Codificar y certificar un Mensaje de Datos Maestros F.1.3 Decodificar un Mensaje de Datos Maestros F.2 Aplicación del tipo Provider F.2.1 Codificar un Mensaje de Datos Maestros F.2.2 Decodificar un Mensaje de Datos Maestros

17 Índice de figuras 2.1 Integración de ICS-API con una aplicación Integración de ICS-API con una aplicación Clasificación de las dimensiones de calidad de datos. Imagen adaptada de [29] Panorama general de ISO/IEC 8000: Esquema de las partes ISO/IEC 8000:2009 utilizadas para este PFC Taxonomía de los datos. Imagen tomada y adaptada [10] Arquitectura de datos para los datos maestros. Imagen tomada y adaptada [10] Diccionario de Datos compuesto de entradas. Imagen tomada y adaptada [15] Ejemplo de Organización de Viaje [34] JAXB: Java Architecture for XML Binding Relación entre los estándares que dan soporte a los Servicios Web. Imagen tomada y adaptada de [22] Ciclo de vida del PUD. Imagen adaptada de [26] Modelo de caso de usos del Agente GestorI8K Modelo de caso de usos del Agente I8K Modelo de caso de usos de ICS-API Diagrama de caso de usos del Agente GestorI8K Diagrama caso de usos del Agente I8K.Cer Diagrama caso de usos del Agente I8K Diagrama caso de usos del Agente I8K.Cer Diagrama caso de usos del Agente I8K.Cer Diagrama caso de usos del Agente I8K.Ev Diagrama caso de usos del Agente I8K.Ev Diagrama de caso de usos de ICS-API.CdU3 Codificar Modelo de despliegue de la Arquitectura de Servicios I8K Diagrama de clases de domino de alto nivel Diagrama entidad-relacional de la base de datos que alberga el Diccionario de Datos Protocolo de comunicación para el intercambio de Mensajes de Datos Maestros con niveles de calidad Pasos necesarios para el intercambio de Mensajes de Datos Maestros Diagramas de casos de uso del Grupo Funcional Diagrama de secuencia de codificar un mensaje desde ICS-API Diagrama de clases ICS-API Diagrama de secuencia de codificar un mensaje en I8K Diagrama de clases del agente I8K xvii

18 xviii ÍNDICE DE FIGURAS 5.22 Test Suite para codificar un mensaje Diagramas de casos de uso del Grupo Funcional Clase MDQManager de ICS-API Diagrama secuencia de decodificar un mensaje en I8K Paquete del diagrama de clases del agente I8K Test Suite para decodificar un mensaje Diagramas de casos de uso del Grupo Funcional Diagrama de clases del agente I8K.Ev Diagramas de casos de uso del Grupo Funcional Diagrama secuencia del proceso de un proveedor de datos Diagramas de casos de uso del Grupo Funcional Prototipo de interfaz de la página web Pruebas realizadas por TripPlanner* F.1 Interfaz de la página web

19 Índice de tablas 2.1 Tabla resumen de los objetivos Ejemplo datos maestros Productos a desarrollar Grupos funcionales Plan de iteraciones Iteración preliminar Iteración Iteración Iteración Iteración Iteración Iteración Iteración Iteración Iteración Iteración Iteración Tipos de mensajes de datos maestros intercambiados entre las aplicaciones e I8K Tipos de mensajes de datos maestros enviados entre una aplicación y un proveedor de datos Tabla resumen de los objetivos conseguidos A.1 Datos Maestros de la organización TripPlanner A.2 Datos Maestros de la organización FlightSA A.3 Mapeo de términos de TripPlanner con FlightSA xix

20

21 Índice de listados 5.1 Ejemplo de fragmento correspondiente a la cabecera de un Mensaje de Datos Maestros codificado Ejemplo de fragmento correspondiente al cuerpo de un Mensaje de Datos Maestros codificado Ejemplo de fragmento correspondiente a las reglas de calidad de un Mensaje de Datos Maestros codificado Ejemplo de fragmento correspondiente a la información de procedencia (provenance) de un Mensaje de Datos Maestros codificado Ejemplo de fragmento correspondiente a la información del nivel de precisión de un Mensaje de Datos Maestros codificado sin certificar el nivel de precisión Ejemplo de fragmento correspondiente a la información del nivel de compleción de un Mensaje de Datos Maestros codificado certificado Ejemplo de archivo service.xml del agente I8K B.1 Esquema XML. Versión C.1 Esquema XML. Versión D.1 Test suite para codificar un mensaje D.2 Test suite para decodificar un mensaje E.1 Mensaje codificado que TripPlanner* ha recibido de I8K y envía a FlightSA E.2 Mensaje decodificado que ha recibido FlightSA de I8K E.3 Mensaje codificado que FlightSA ha recibido de I8K, y va a enviar a Trip- Planner* E.4 Mensaje decodificado que TripPlanner* ha recibido de I8K xxi

22

23 Capítulo 1 Introducción 1.1 Dominio del problema y naturaleza de la solución propuesta Las organizaciones necesitan datos para sus procesos organizacionales [9] y es un hecho objetivo que, junto a las personas, los datos son uno de sus activos más importantes [27]. Y efectivamente, se tiende a tratarlos como tal [42], ya que, la mayor parte de las organizaciones ven en la tenencia de datos un medio indispensable para hacer frente a un mercado cada día más competitivo [25]. De todos los datos que posee una organización, una parte de ellos, que son esenciales para sus procesos de negocio, son los Datos Maestros [28]. Los Datos Maestros son críticos para las organizaciones y como se ha mencionado anteriormente, una base fundamental para los procesos de negocio de éstas [19]. Algunos ejemplos de Datos Maestros son los datos de los clientes, empleados, compañías aéreas, hoteles, ciudades, etc. Redman [37] afirmó que los datos de las organizaciones añaden un gran valor a los procesos de negocio (BP). Estos procesos van desde el marketing y el desarrollo de nuevos productos, hasta estrategias de gestión financiera. Sin embargo, gran parte de las organizaciones no utilizan bien sus datos para lograr ventajas estratégicas; esto es [37] porque no los utilizan o porque son erróneos, lo que puede hacer que la mayoría de las operaciones y procesos de toma de decisiones fracasen o no consigan sus objetivos; y las decisiones no son mejores que los datos sobre los que se toman [36]. Malas decisiones desencadenarán en problemas técnicos, legales, operativos,... pudiendo así representar una verdadera amenaza para las bases del negocio de las organizaciones [21]. Un Proceso de Negocio (Business Process-BP) consiste en un conjunto de actividades que combinadas adecuadamente, logran un objetivo de negocio en un entorno organizativo y

24 21.1. DOMINIO DEL PROBLEMA Y NATURALEZA DE LA SOLUCIÓN PROPUESTA técnico [41]. No obstante, en ocasiones, como resaltan Parody et al. en [34], la combinación de actividades para obtener un objetivo global puede llegar a ser una tarea muy compleja. Concretamente, la complejidad aumenta cuando los valores de entrada de una actividad dependen de los valores de salida de otras actividades, el orden de ejecución entre las actividades no es claro y las actividades tienen que buscar el óptimo global. Un ejemplo de aplicación en el que se combinan actividades, y en donde pueden surgir este tipo de problemas es la aplicación Organizador de Viajes TripPlanner [16], desarrollada por [34]. El propósito de esta aplicación consiste en buscar la combinación de vuelo, hotel y alquiler de coche que satisfaciendo las necesidades del usuario (por ejemplo, fecha de inicio y de fin, flexibilidad en días,...), resulte con el coste más económico posible. Esto se plantea como un proceso que busca la optimización de una función objetivo con restricciones. En primer lugar el cliente hace una petición de reserva/búsqueda del viaje. TripPlanner busca y evalúa todas las combinaciones disponibles que optimizan la función objetivo y se las ofrece al cliente. De entre las diferentes alternativas, el cliente selecciona una de las propuestas o cancela la petición. Puede ocurrir que cuando las fechas de salida y regreso proporcionadas por el cliente tienen valores atómicos, TripPlanner consigue realizar de forma paralela la búsqueda de vuelo, de la habitación de hotel y del alquiler de coche. Pero si en vez de proporcionar valores individuales, se especifica un rango de posibles valores para ambas fechas, entonces la búsqueda paralela no se puede llevar a cabo. Por otra parte, hay que tener en cuenta las restricciones semánticas existentes entre los datos, como por ejemplo, que la fecha de vuelta y la salida del hotel coincidan. En el trabajo desarrollado por Parody et al. en [34] se muestra que se puede determinar el mejor conjunto de valores del rango de entrada que optimiza la función objetivo y que satisface todas las restricciones. Para ello, TripPlanner solicita a los proveedores de viajes los datos necesarios para evaluar las combinaciones. Una vez recopilados todos los datos compatibles con la petición, el algoritmo busca la solución óptima que ofrecer al cliente. TripPlanner usa instancias de objetos genéricos que son clave para el BP. Dichos objetos son Datos Maestros críticos para la organización y una base fundamental para el proceso de negocio [19]. Como se puede intuir de los hechos mostrados, la aplicación TripPlanner necesita muchos datos, que debe importar de los distintos distribuidores de datos y/o marketplace. Estos datos son proporcionados por los diferentes proveedores de viajes siguiendo un protocolo

25 CAPÍTULO 1. INTRODUCCIÓN 3 preestablecido para el intercambio de datos. Este protocolo debería ser sensible a incoherencias en los datos, como por ejemplo que un dato con un mismo nombre signifique conceptos diferentes pues este tipo de incoherencias en los datos ocasiona problemas en la búsqueda de la solución óptima. Por este motivo, debería ser necesario algún tipo de mecanismo para regir la calidad de los datos, el uso y sincronización dentro de la aplicación y en los intercambios para tratar dichas incoherencias. La Gestión de Datos Maestros (Master Data Management, MDM), permite afrontar este tipo de problemas. Una aproximación a la Gestión de Datos Maestros en el intercambio de mensajes la proporciona la familia de estándares ISO/IEC 8000: El objetivo principal de este Proyecto Final de Carrera (PFC) es proporcionar productos software que permitan gestionar la calidad de los Datos Maestros mediante la implementación del estándar ISO/IEC 8000:2009 partes 100 [10], 102 [14], 110 [15], 120 [11], 130 [12] y 140 [13]. Además, los resultados obtenidos se probarán con la aplicación TripPlanner para comprobar la validez de los mismos. Las partes especificadas de la familia de estándares proponen usar un formato preestablecido para los Mensajes de Datos Maestros intercambiados en la comunicación entre clientes y proveedores (por ejemplo entre TripPlanner y todas aquellas agencias de viajes que le proporcionan datos para hacer las búsquedas). Además, se especifican los requisitos que deben cumplir dichos mensajes para incorporar información sobre el nivel de Calidad de los Datos Maestros contenidos en el Mensaje de Datos Maestros y poder así gestionarla como parte del mismo procesamiento de los datos. Para ello se van a desarrollar dos productos software: una Arquitectura de Servicios, llamada I8K, que contiene los agentes necesarios para el proceso de intercambio de datos, y de evaluación y certificación de la Calidad de los Datos en los Mensajes de Datos Maestros; y una Interfaz de Programación de Aplicaciones, llamada ICS-API, que aportará a las aplicaciones que lo requieran (como TripPlanner y sus correspondientes proveedores de datos), las funcionalidades necesarias para comunicarse con dicha arquitectura. Actualmente, sólo existe una implementación públicamente utilizable del estándar ISO/IEC 8000:2009, la desarrollada por ECCMA, que está accesible en [23]. Sin embargo, dado que esta implementación no está aún funcionalmente completa y su uso no es gratuito, decidimos llevar a cabo nuestra propia implementación.

26 CONTEXTUALIZACIÓN DEL PROYECTO 1.2 Contextualización del proyecto Este PFC se encuentra enmarcado dentro del proyecto PEGASO/MAGO (TIN C02-01). Se ha desarrollado en colaboración con el proyecto TDiaCO-BPMS (TIN ) de la Universidad de Sevilla. Ambos proyectos se encuentran subvencionados por el Ministerio de Ciencia y Tecnología de España y por el Fondo Europeo de Desarrollo Regional (ERDF/FEDER). 1.3 Estructura del documento En el Capítulo 1, que es el actual, se introduce la problemática a tratar y se detalla la estructura del documento. En el Capítulo 2 se exponen los objetivos que se pretenden alcanzar con el desarrollo de este PFC. El Capítulo 3 se revisa con el estado del arte. Se centra la atención en los aspectos que han servido de fundamentos teóricos para este proyecto. Estos aspectos son Calidad de Datos y Gestión de Datos Maestros junto con la familia de estándares ISO/IEC 8000: También se detalla una descripción de TripPlanner, la aplicación utilizada para el ejemplo de aplicación. Por último, se detallan algunos aspectos tecnológicos de especial relevancia para el desarrollo del proyecto. En el Capítulo 4 se explica cómo usar el Proceso Unificado de Desarrollo para la realización de este proyecto. También se identifican las herramientas y entornos que se han sido utilizados para llevar a cabo el desarrollo del PFC. El Capítulo 5 recoge y muestra los resultados y artefactos que se han ido obteniendo a lo largo del ciclo de vida del desarrollo del presente proyecto. En el Capítulo 6 se revisa la consecución de los objetivos, y se presentan las líneas de trabajo futura. También se enumeran las publicaciones que se han enviado a diferentes foros nacionales e internacionales como resultado de los avances del proyecto. Finalmente una opinión personal. Tras los capítulos mencionados, aparece la Bibliografía consultada para la realización de este proyecto. Finalmente, se presentan una serie de anexos a los que se hace referencia a lo largo del

27 CAPÍTULO 1. INTRODUCCIÓN 5 presente documento. Dicho anexos son: Anexo A. Modelo de Datos Maestros para el dominio de la aplicación TripPlanner Anexo B. Esquema XML del formato de los Mensaje de Datos Maestros, versión 1. Anexo C. Esquema XML del formato de los Mensaje de Datos Maestros, versión 2. Anexo D. Código de los casos de prueba. Anexo E. Ejemplo de traza del TripPlanner y el proveedor FlightSA. Anexo F. Manual de usuario.

28

29 Capítulo 2 Objetivos del PFC En este capítulo se describen, el objetivo principal de este PFC, y los objetivos parciales o específicos en los que se desglosa en objetivo principal. 2.1 Objetivo Principal El objetivo principal de este PFC es dar soporte a la implementación del estándar ISO/IEC 8000:2009 partes 100, 102, 110, 120, 130 y 140. Dichas partes del estándar proponen usar un formato preestablecido para los Mensajes de Datos Maestros intercambiados en la comunicación entre aplicaciones. Los términos correspondientes a los Datos Maestros del mensaje se almacenan en un diccionario. Además las partes, especifican los requisitos que deben cumplir dichos mensajes para incorporar información sobre el nivel de Calidad de los Datos contenidos en él, respecto a las dimensiones de calidad de Precisión y Compleción. En la sección se puede encontrar una descripción más detallada del estándar. Este objetivo principal se desglosa en una serie de objetivos parciales relacionados con la arquitectura y funcionalidades del sistema que se va a desarrollar. 2.2 Objetivos parciales o específicos Para llevar a cabo la consecución del objetivo principal, se han de cumplir unos objetivos parciales o específicos. O1. Elaboración de una Arquitectura de Servicios, llamada I8K, que de soporte a las operaciones indicadas en el estándar. Dicha arquitectura acreditará y certificará el nivel de Calidad de los Datos Maestros de los Mensajes de Datos Maestros intercambiados

30 OBJETIVOS PARCIALES O ESPECÍFICOS entre las aplicaciones de datos. Para poder dotar a esta arquitectura de la funcionalidad necesaria, se tendrán que conseguir estos subobjetivos. O1.1. Desarrollo de un Vocabulario de soporte al Protocolo de Comunicación de Mensajes de Datos Maestros entre las aplicaciones y la Arquitectura de Servicios. O1.2. Definición y creación de un Modelo de Datos Maestros para el dominio específico del ejemplo del TripPlanner, sobre el que se pueda construir un Diccionario de Datos, necesarios para el intercambio de Mensajes de Datos Maestros, tal y como demanda el proyecto. O1.3. Definición y creación de un Diccionario de Datos donde se almacenen los términos y la información relevante de estos. Siendo los términos, datos que posee una organización y que describe entidades independientes y fundamentales para la organización. Los términos se corresponden Datos Maestros de la organización. O1.4. Definición de un Protocolo de Comunicación para el intercambio de los Mensajes de Datos Maestros tanto entre aplicaciones como entre aplicaciones y la Arquitectura de Servicios. O1.5. Diseño e implementación de un vocabulario específico para dar soporte al Protocolo de Comunicación entre las aplicaciones (cliente y proveedor) para el intercambio de Mensajes de Datos Maestros a partir de la especificación de una sintaxis formal que requiere el estándar. Para este objetivo, en este PFC, se empleará tecnología XML (extensible Markup Language). O1.6. Definición de un Protocolo de Comunicación entre los diferentes Agentes de la Arquitectura de Servicios. O1.7. Diseño y creación de un Agente encargado de la codificación y decodificación de los Mensajes de Datos Maestros. O1.8. Diseño y creación de Agentes encargados de la evaluación de las dimensiones de Calidad especificadas en ISO/IES 8000: e ISO/IEC 8000: O1.9. Diseño y creación de Agentes encargados de la certificación de los Mensajes de Datos Maestros para cada una de las dimensiones identificadas por el estándar.

31 CAPÍTULO 2. OBJETIVOS DEL PFC 9 O2. Desarrollo de una Interfaz de Programación de Aplicaciones, llamada ICS- API, (Interface Communication Services-API), para facilitar que las aplicaciones se comuniquen con la Arquitectura de Servicios I8K. O2.1. Desarrollo e implementación de las funcionalidades para que las aplicaciones puedan configurar los datos necesarios para realizar la comunicación. Como queda reflejado en los objetivos O1 y O2, el desarrollo de este PFC está formado por dos productos diferentes, la Arquitectura de Servicios I8K y una Interfaz de Programación de Aplicaciones ICS-API. En la Figura 2.1 se muestra la integración de ICS-API con una aplicación y como proporciona el soporte a la comunicación con I8K. Figura 2.1: Integración de ICS-API con una aplicación. O3. Probar los componentes desarrollados mediante la aplicación a un caso de estudio en el dominio de viajes de la aplicación TripPlanner. En la Figura 2.2 se muestra la integración de ICS-API con TripPlanner y un proveedor de datos. Figura 2.2: Integración de ICS-API con una aplicación. En la Tabla 2.1, se muestra un resumen de los subobjetivos detallados anteriormente que servirán para alcanzar el objetivos principal de este PFC.

32 OBJETIVOS PARCIALES O ESPECÍFICOS Id. Objetivo O1 Objetivos Creación de una Arquitectura de Servicios O1.1 Vocabulario de soporte al Protocolo de Comunicación O1.2 Modelo de Datos Maestros para el dominio de TripPlanner O1.3 Definición y creación de un Diccionario de Datos O1.4 Definición de un Protocolo de Comunicación entre aplicaciones e I8K O1.5 Vocabulario para el intercambio de mensajes O1.6 Definición de un Protocolo de Comunicación entre agentes O1.7 O1.8 O1.9 O2 O2.1 O3 Diseño y creación de un Agente encargado de la codificación y decodificación de mensajes Diseño y creación de Agentes encargados de la evaluación de las dimensiones de Calidad Diseño y creación de Agentes encargados de la certificación de los mensajes Desarrollo de un API Desarrollo de funcionalidades para la comunicación de aplicaciones con I8K Probar los componentes desarrollados con la aplicación TripPlanner Tabla 2.1: Tabla resumen de los objetivos.

33 Capítulo 3 Estado del Arte En este capítulo se describen los conocimientos teóricos necesarios para fijar las bases en las que se ha basado la elaboración de este PFC. Entre estos conocimientos se encuentran los conceptos de Calidad de Datos y la Gestión de Datos Maestros, la familia de estándares ISO/IEC 8000: , una descripción del ejemplo de aplicación, llamada TripPlanner, y finalmente aspectos teóricos relevantes sobre las tecnologías que se han utilizado como desarrollo. 3.1 Calidad de datos y Gestión de Datos Maestros Concepto de calidad de datos La definición más aceptada de calidad de datos es "fitness for use"[18]. Es decir, los datos deben tener características para que puedan ser utilizados para la tarea que se requiere. En [18] se muestra que las consecuencias de una mala calidad de los datos se experimenta a menudo en la vida cotidiana. Por ejemplo, un automático duplicado, suele ser indicativo de una base de datos con errores de duplicación de registros. Las organizaciones tienden a recopilar la mayor cantidad de datos posibles bajo la premisa de que cuantos más datos, más competitivos. Sin embargo, este almacenamiento masivo de datos desencadena problemas como datos no usados, barreras en la accesibilidad a ellos o incluso dificultad en su utilización [38]. Estos problemas suponen un impacto al rendimiento del negocio, por lo que puede decirse que la calidad de los datos debería convertirse en un factor clave de cualquier estrategia de negocio de cualquier organización. Por tanto, la calidad de los datos es uno de los componentes clave de cualquier estrategia de negocio [19]. Para evaluar la calidad de los datos hay que identificar una serie de dimensiones de calidad

34 CALIDAD DE DATOS Y GESTIÓN DE DATOS MAESTROS de los datos. Generalmente se habla sólo de la dimensión de precisión de los datos [18], sin embargo, son también necesarias otras dimensiones. Cada dimensión representa los requisitos de calidad de datos de los usuarios. Según [29] una dimensión de calidad de datos describe un contexto y un marco de referencia para la medición de la calidad con unas unidades de medidas sugeridas. Para cada una de las dimensiones elegidas, habrá que desarrollar una serie de medidas que sirve para cuantificar el nivel de calidad de datos en la dirección apuntada por la dimensión. La forma de definir dichas medidas, depende fuertemente del contexto de uso de los datos. Para poder medir las dimensiones de calidad de datos sobre un conjunto de datos en un contexto determinado, las organizaciones deben: Definir reglas de calidad de datos que representen la validez de estos. Determinar unos umbrales mínimos de aceptabilidad. Comprobar la calidad de los datos contra esos umbrales. En [29], se dividen las dimensiones de calidad de datos en dos grupos: Intrínsecas: se centran en los valores de los datos en sí, sin evaluar necesariamente el contexto de estos valores. Contextuales: dependen del contexto para revisar la conformidad de calidad de los datos en la forma en la que están relacionados entre sí. En la Figura 3.1 se muestra la clasificación de las dimensiones de calidad de datos y sus relaciones. Figura 3.1: Clasificación de las dimensiones de calidad de datos. Imagen adaptada de [29].

35 CAPÍTULO 3. ESTADO DEL ARTE 13 Sin embargo, el conjunto de dimensiones de calidad de datos, más ampliamente aceptada es la propuesta en [39], que identifica las siguientes dimensiones: Intrínsecas (Precisión, objetividad y credibilidad) Accesibilidad (Accesibilidad y seguridad en el acceso) Contextual (Relevancia, valor añadido y oportunidad) Representacional (Interpretabilidad y facilidad de comprensión) Datos Maestros y Gestión de Datos Maestros A lo largo de su vida, las organizaciones han ido recopilando una gran cantidad de datos referentes a los conceptos claves de su actividad organizacional. Estos datos han tenido que ser adaptados previamente para que les sean útiles y poder así interpretarlos e intercambiarlos con otras aplicaciones y/u organizaciones [28]. Estos datos describen objetos clave de sus negocios y reciben el nombre de Datos Maestros [33]. Los Datos Maestros como se ha mencionado en el Capítulo 1 son entidades, relaciones y atributos críticos para las organizaciones y a su vez para los procesos clave de negocio y sistemas de aplicación [28]. Ejemplos de Datos Maestros son los datos de los clientes, empleados, vendedores, etcétera. En los datos maestros se pueden diferenciar tres conceptos [32]: Clase de datos maestros Atributo de datos maestros Objeto de datos maestros Un objeto de datos maestros representa una instancia de una clase de datos maestros. Por ejemplo un vuelo, el objeto concreto sería un vuelo de una compañía aérea determinada en un momento en el tiempo determinado. Las características de precio y ciudad origen pueden especificarse por medio de atributos de datos maestros [32]. Las organizaciones comparten sus datos con otras organizaciones a través de aplicaciones. Un problema que puede surgir en estos intercambios son incoherencias en los datos. Por ejemplo, en muchas ocasiones los datos utilizados por varias organizaciones u aplicaciones se refieren a los mismos conceptos pero no reciben el mismo nombre. También puede suceder que el mismo dato se utilice para identificar instancias de conceptos diferentes, o por el contrario que conceptos distintos reciban el mismo nombre [28]. Por ejemplo, hay un vuelo IBR4499, con destino el aeropuerto de Barajas de Madrid. Los datos maestros que se tienen son vuelo y

36 CALIDAD DE DATOS Y GESTIÓN DE DATOS MAESTROS destino, vuelo toma el valor IBR4499 y destino toma dos valores, Madrid y Barajas (véase Tabla 3.1). Destino se utiliza para identificar dos instancias de conceptos diferentes, uno es la ciudad de destino y otro es el aeropuerto de destino. Esto, desde el punto de vista de la aplicación supone un problema porque el software no tiene por qué saber que Barajas está en Madrid, como lo sabría un humano. Este tipo de conflicto puede ocasionar problemas operativos en la gestión de negocios, por lo que la organización necesita mecanismos para gestionar adecuadamente los datos usados, así como para la sincronización en el intercambio de datos entre organizaciones, evitando así conflictos como el citado anteriormente. Por tanto, teniendo en cuenta la importancia de los datos maestros dentro de las organizaciones, se hace necesaria una Gestión de Datos Maestros (Master Data Management, MDM). Dato Maestro Vuelo Destino Destino Valor IBR4499 Barajas Madrid Tabla 3.1: Ejemplo datos maestros. La MDM comprende todas las actividades necesarias para la creación, modificación o supresión de los tres conceptos definidos anteriormente que caracterizan a los datos maestros, una clase datos maestros, un atributo de datos maestro o un objeto de datos maestros [32]. Por ejemplo, algunas de esas actividades podrían ser el modelado, la provisión, gestión de calidad, mantenimiento y el almacenamiento de datos maestros. La ejecución de las actividades puede incidir en la calidad de los datos, por lo que es importante que dichas actividades, dentro del alcance de su propia actividad, tengan en cuenta la calidad de sus datos. De tal modo que si los datos cumplen las dimensiones de calidad requeridas, los procesos de negocio donde se utilicen tendrán calidad [32]. Loshin en [28] define MDM como una recopilación de las mejores prácticas de gestión de datos orientadas a la integración de los datos. Estas prácticas se integran en las aplicaciones de negocio, gestión de información, y herramientas para la gestión de datos que implementan procedimientos, servicios e infraestructura para el soporte de la captura, integración y compartición de los Datos Maestros. La MDM tiene asociados beneficios como el incremento de la calidad de los datos [31]. Una organización puede emprender acciones de evaluación y mejora de calidad de datos sin tener en cuenta mecanismos para la MDM. Sin embargo, la

37 CAPÍTULO 3. ESTADO DEL ARTE 15 situación contraria no es posible, debido a que la MDM implica unos datos de calidad [24] ya que la gestión de la calidad de los datos en considerada una parte integral de MDM dentro de las organizaciones. Los beneficios que aporta la MDM a los negocios son [28]: Poseer un conocimiento exhaustivo de los datos maestros de la organización. Ofrecer un mejor servicio al cliente. Coherencia en los datos maestros. Mejora en la competitividad. Mejora en la gestión de riesgos. Mejora de la eficiencia operativa, con una reducción de costes. Mejora en la toma de decisiones. Mayor calidad de los datos maestros y con ello de la información. Mejora la productividad empresarial. Un producto software que de soporte a MDM debe: Permitir la incorporación de datos desde fuentes de datos heterogéneas donde se encuentren todos los datos maestros. Poseer un sitemas central donde se encuentren todos los datos maestros. Tener disponible una única vista de los datos maestros para las aplicaciones implicadas. Controlar el flujo de datos maestros que se intercambien entre organizaciones y/o aplicaciones. Las implementaciones de MDM se especializan según los siguientes aspectos: La instanciación de los datos maestros propios de la organización. El uso que reciban los datos maestros en la organización. La estructura de la organización, si los datos maestros se distribuyen entre pocas aplicaciones o se distribuyen entre muchas. La latencia y accesibilidad de los datos maestros de la organización.

38 CALIDAD DE DATOS Y GESTIÓN DE DATOS MAESTROS Familia de estándares ISO/IEC: La familia de estándar ISO/IEC 8000: está formada por varias partes. Inicialmente, y dado que fueron las primeras partes en ser publicadas, cuando habitualmente se habla de ISO/IEC 8000:2009, se está haciendo referencia implícita a ISO/IEC 8000:2009 partes 100 a 140. Actualmente se están desarrollando más partes para cubrir aspectos específicos (véase Figura 3.2). Figura 3.2: Panorama general de ISO/IEC 8000:2009 Para el desarrollo de este PFC nos hemos centrado en las partes 100 [10], 102 [14], 110 [15], 120 [11], 130 [12] y 140 [13] del estándar ISO/IEC 8000:2009. Dichas partes del estándar proponen usar un formato preestablecido para los Mensajes de Datos Maestros (véase más adelante la Definición 5) intercambiados en la comunicación entre aplicaciones, dentro de una misma organización o entre organizaciones. Además, se especifican los requisitos que deben cumplir dichos mensajes para incorporar información sobre el nivel de Calidad de los Datos contenidos en el Mensaje de Datos Maestros, respecto a las dimensiones de calidad de Precisión y Compleción. En la Figura 3.3 se muestra un esquema de las partes. Los usuarios de las partes objetos de este estándar son: Proveedores de datos: entienden las necesidades de datos del resto de los usuarios y los requisitos de calidad sobre ellos que se espera de ellos. Por ejemplo, una Agencia de viajes. Consumidores (clientes de datos): demandan datos con un cierto nivel de calidad. Por ejemplo, un cliente Web.

39 CAPÍTULO 3. ESTADO DEL ARTE 17 Figura 3.3: Esquema de las partes ISO/IEC 8000:2009 utilizadas para este PFC Custodios de datos: se encargan del almacenamiento de los datos, teniendo en cuenta los requisitos de datos que se necesitan para guardar datos con la calidad proyectada por los proveedores, y los requisitos necesarios para servir datos con la calidad demandada por los clientes. Por ejemplo, la Arquitectura de Servicios I8K. En algunas ocasiones un proveedor de datos es también el custodio de los mismos. Cada una de las partes del estándar cubre uno de los aspectos mencionados anteriormente. ISO/IEC 8000: La parte ISO/IEC 8000: [10] describe los aspectos específicos de Datos Maestros para gestionarlos en sistemas de Gestión de Calidad de datos. Dentro de una organización, los datos maestros describen cosas con un especial significado para ella. En la Figura 3.4 se muestra una taxonomía de los datos, y se muestra donde se encuadran los datos maestros. Se puede observar que los datos maestros son datos y a su vez se dividen en datos de referencia o datos característicos. En las transacciones de negocio, los datos maestros son referenciados por medio de un identificador. Este identificador hace referencia al dato y al registro de datos maestros donde se encuentra descrito el dato. No se debe confundir el dato propiamente dicho, con el valor que pueda tomar, por ejemplo el dato Fecha toma como valor " ". El registro de datos maestros es un repositorio central donde se encuentran almacenados todos los datos maestros. Se debe tener en cuenta que los datos maestros no son necesariamente estáticos por lo que sus características pueden variar.

40 CALIDAD DE DATOS Y GESTIÓN DE DATOS MAESTROS registra el resultado de evaluar o determinar la magnitud o cantidad de algo representa la realización de una acción de negocio, o el curso de una acción dato datos medidos datos transaccionales datos maestros describe las entidades que son independientes y fundamentales para la organización; debe hacer referencia a realizar transacciones. definido por referencia a los datos maestros de otra organización datos de referencia definido por las características de la entidad que se está describiendo datos característicos Figura 3.4: Taxonomía de los datos. Imagen tomada y adaptada [10]. Algunos ejemplos de datos maestros con sus características, dentro de una organización son: vendedor: localización, estatus legal,... cliente: información de contacto, tarjeta de crédito,... material: ítem tangible,... localización: calle, número, ciudad, código postal,... La arquitectura de datos que propone el estándar ISO/IEC 8000:2009 para la gestión de datos maestros se puede observar en la Figura 3.5. Se propone que junto a los datos maestros se incluya información sobre la procedencia de los datos, la precisión de los datos y la compleción de los datos. Los datos maestros se codifican utilizando conceptos de un diccionario de datos. Dichos datos están conformes a una especificación de datos y se ajustan a una sintaxis formal. Por otro lado, una especificación de datos recoge los requisitos de datos para la codificación de datos maestros utilizando conceptos de un diccionario de datos. Dicha especificación se puede hacer de acuerdo a la terminología preferida para los conceptos del diccionario de datos. Además especifica el uso de una sintaxis formal. Los datos maestros, especificaciones de datos y el diccionario de datos utilizan identificadores de un esquema de identificación. ISO/IEC 8000: La parte ISO/IEC 8000: [14] describe el vocabulario relacionado con la Calidad de Datos Maestros referente en las distintas partes del estándar. Algunos de los términos que se han estudiado en profundidad y se van a utilizar en este PFC son:

41 CAPÍTULO 3. ESTADO DEL ARTE 19 usa identificadores de Dato Maestro provenance exactitud completitud conforme a Sintaxis Formal para los Datos Maestros conforme a es codificado usando los conceptos de especifica el uso de especifica requisitos de datos (plantillas, reglas y restricciones) para codificar los datos maestros usando conceptos de Especificación de Datos usa identificadores de Diccionario de Datos especifica la terminología adecuada para los conceptos en usa identificadores de Esquema identificativo Figura 3.5: Arquitectura de datos para los datos maestros. Imagen tomada y adaptada [10]. DEFINICIÓN 1 Pareja (propiedad, valor): instancia de un valor específico junto con un identificador de la entrada del diccionario de datos que define una propiedad. DEFINICIÓN 2 Diccionario de datos: colección de entradas de diccionario de datos que permiten búsqueda por identificador de la entidad. DEFINICIÓN 3 Entrada del diccionario de datos: descripción de un tipo de entidad que contiene, como mínimo, un identificador único, un término, y una definición. En la Figura 3.6 se muestra un esquema del Diccionario de Datos con sus entradas. Figura 3.6: Diccionario de Datos compuesto de entradas. Imagen tomada y adaptada [15] DEFINICIÓN 4 Codificación semántica: técnica de reemplazo natural de términos de un lenguaje en un mensaje con identificadores que se refieren a entradas del diccionario de

42 CALIDAD DE DATOS Y GESTIÓN DE DATOS MAESTROS datos. DEFINICIÓN 5 Mensaje de Datos Maestros: es un mensaje usado para el intercambio de Datos Maestros entre organizaciones. ISO/IEC 8000: La parte ISO/IEC 8000: [15] establece los términos en los que se codifican los Mensajes de Datos Maestros (aspectos sintácticos, codificación semántica y requisitos) para que puedan ser intercambiados entre organizaciones y aplicaciones. Por ejemplo, un Mensaje de Datos Maestros es un mensaje que envía un proveedor de aviones a un cliente con la información sobre un el número de vuelo, el destino del vuelo, etcétera. Establece que todo Dato Maestro puede ser representado en forma pareja(propiedad, valor) (véase Definición 1). La propiedad debe estar almacenada en un Diccionario de Datos (véase Definición 2). Por ejemplo, la pareja (Destination, 01-02# #1), donde propiedad es Destination y su valor 01-02# #1. Dicho diccionario debe ser accesible en formato electrónico. Los Mensajes de Datos Maestros están compuestos de parejas(propiedad, valor). Los requisitos mínimos que debe cumplir un Mensaje de Datos Maestros son: Un mensaje de datos maestros no debe tener ambigüedad, conteniendo toda la información necesaria para que el remitente determine su significado. Un mensaje de datos maestros debe cumplir una sintaxis formal. Un mensaje de datos maestros se especifica usando un lenguaje computacionalmente interpretable. Se tiene que poder verificar la exactitud (corrección) del mensaje de datos maestros de acuerdo a la sintaxis formal. Los Mensajes de Datos Maestros tienen que estar codificados semánticamente. Las referencias dentro de un mensaje de datos maestros para las entradas del diccionario de datos deberá estar en la forma de identificadores no ambiguos que pertenecen a un esquema reconocido internacionalmente. Respecto a la sintaxis formal, los Mensajes de Datos Maestros tienen que contener en su cabecera una referencia a ella.

43 CAPÍTULO 3. ESTADO DEL ARTE 21 Respecto a la codificación semántica, (véase Definición 4) se refiere a que términos en lenguaje natural en un mensaje deben estar sustituidos por referencias a entradas del diccionario de datos. Cada referencia debe estar en forma de un identificador inequívoco. ISO/IEC 8000: La parte ISO/IEC 8000: [11] establece la forma en la que se puede añadir información sobre el ciclo de vida de los datos y la procedencia y evolución de éstos. El término procedencia de datos hace referencia a "historia o la genealogía/linaje de una pareja(propiedad, valor)". Es decir, el registro del ciclo de vida de los datos maestros contenidos en un mensaje. El registro de procedencia de datos para un mensaje de datos maestros es un registro de la última derivación y paso del mensaje a través de varios custodios. Dicho registro debe incluir: Fecha y hora del último evento producido en el mensaje. Identificador de la organización propietaria de los datos maestros del mensaje, es decir quién posee el diccionario de datos donde están almacenados los datos (la interpretación de los términos) contenidos en el mensaje. Identificador de la organización que suministra los datos maestros. Tipo de evento realizado sobre el mensaje de datos maestros, es decir si se ha leído, modificado, etcétera. Quién realizó el evento. ISO/IEC 8000: La parte ISO/IEC 8000: [12] establece cómo añadir información sobre el grado de precisión que tienen los datos. La precisión de un proceso para crear/modificar un dato, determinará la precisión del dato en términos de su proximidad al valor verdadero, entendiendo como verdadero, aquel que tiene la instancia en el Mundo Real. La precisión de una transferencia de datos desde un sistema a otro puede también afectar a la precisión del dato. Por tanto la precisión de la transferencia de datos puede ser medida por comparación con la fuente de datos autorizada. Un proveedor de datos puede declarar la precisión de los datos a través de una representación/declaración o de una garantía. Donde una representación de la precisión de los datos es

44 EJEMPLO DE APLICACIÓN: TRIPPLANNER una declaración de hecho que permite al receptor emitir juicio sobre si los datos cumplen los requisitos que este tiene de los datos de precisión, siendo estos metadatos que describen dicho nivel; y una garantía de la precisión de los datos es una garantía de que el valor propiedad cumple con alguna medida objetiva de la precisión de los datos. El registro de la precisión de los datos maestros contenidos en un Mensaje de Datos Maestros tiene que contener, el tipo de evento, quién ha evaluado los datos maestros del mensaje, la fecha y hora y el nivel de precisión que poseen dichos datos. ISO/IEC 8000: La parte ISO/IEC 8000: [13] establece cómo añadir información sobre el grado de compleción que tienen los datos. De manera similar a la parte de estándar anteriormente comentada, un proveedor de datos puede declarar la compleción de los datos a través de una representación/declaración o una garantía. El registro de la compleción de los datos maestros contenidos en un Mensaje de Datos Maestros tiene que contener, el tipo de evento, quién ha evaluado los datos maestros del mensaje, la fecha y hora y el nivel de compleción que poseen dichos datos. 3.2 Ejemplo de aplicación: TripPlanner Se considera una aplicación para buscar viajes tanto a empresas como a particulares, llamada TripPlanner [35]. Los viajes se componen de transporte y estancia. TripPlanner, en particular, proporciona a sus clientes las mejores combinaciones de vuelos, hotel y alquiler de coches (si fuera necesario ir a otro aeropuerto a coger el avión). Generalmente, cuando un usuario busca un viaje, en el caso de tener problemas en el vuelo de salida, por ejemplo, no hay vuelos el día que se quiere viajar desde el aeropuerto más cercano, el usuario elige entre cambiar: la fecha de salida, el aeropuerto de salida a otro distinto o la compañía de vuelo, o simplemente esperar a que haya un hueco libre. Hay que tener en cuenta que un cambio en la fecha de salida implicaría un cambio en la reserva del hotel. Por otro lado, un cambio en el aeropuerto de salida necesitará cambiar no solo la reserva del vuelo sino alquilar un coche para ir a dicho aeropuerto. Por este motivo, TripPlanner, permite al usuario introducir un rango de fechas y aeropuertos sobre los que poder realizar la búsqueda del mejor viaje.

45 CAPÍTULO 3. ESTADO DEL ARTE 23 Figura 3.7: Ejemplo de Organización de Viaje [34]. TripPlanner busca el mejor viaje teniendo en cuenta que el precio total sea el mínimo posible. El precio del viaje dependerá de los precios del vuelo, hotel y alquiler de coche. No por elegir el vuelo más barato significa que el viaje vaya a ser el más barato porque puede que se necesite alquilar un coche para desplazarse al hotel o para ir de tu casa al aeropuerto, aumentando por lo tanto el precio final. De forma que una buena combinación de vuelos, hotel y alquiler de coche hará que el precio del viaje sea el menor posible. La forma de calcular el precio de cada uno (avión, hotel y alquiler de coche) dependerá de las compañías, fechas, etcétera, que son decisiones de gestión internas de cada una, de forma que tendrán que llegar a un acuerdo para cumplir y obtener el objetivo global. Por lo tanto, el objetivo del TripPlanner es buscar un paquete de viajes minimizando el coste total del viaje teniendo en cuenta las preferencias del usuario. El paquete de viajes incluyen billetes de avión, hotel y alquiler de coche (si fuera necesario) para las ciudades y fechas que el usuario desee. El proceso de negocio completo del TripPlanner es el que se muestra en la Figura 3.7. En primer lugar, se recibe la petición del usuario con las preferencias del viaje. Después, se realiza la búsqueda de la mejor combinación de valores para el avión, hotel y alquiler de coche que formarán el paquete de viaje; dichos valores han sido solicitados a los correspondientes servicios web que implementan las actividades. Una vez realizada la búsqueda, se le ofrece al usuario los paquetes de viajes candidatos (que por la naturaleza del algoritmo que los genera son de por sí soluciones óptimas) para que decida si quiere aceptar algún paquete de viaje. Finalmente, según lo que decida el usuario, la reserva se formaliza o se cancela. Hasta el momento, el usuario proporcionaba únicamente los datos necesarios para organizar un viaje: fechas de salida y regreso, y las ciudades origen y destino. Además, para flexibilizar la búsqueda, el usuario también proporciona, unos márgenes de fecha, y un radio de kilómetros (para poder ir a otros aeropuertos) para encontrar el viaje más barato. Teniendo

46 ASPECTOS TECNOLÓGICOS en cuenta los datos proporcionados por el usuario (fechas de salida y regreso, y las ciudades origen y destino, márgenes de fecha, y un radio de kilómetros -para poder ir a otros aeropuertos-,...) y las restricciones semánticas existentes para el intercambiados de estos entre las distintas actividades, TripPlanner realiza las llamadas necesarias a los distintos servicios para obtener la información de cada una de las partes (precio del vuelo, precio de la habitación de hotel y precio del alquiler del coche), y a continuación diseña la posible solución global y la evalúa en función del objetivo global, que en este caso es minimizar el precio total del viaje. Sin embargo, hay aspectos que al combinar las actividades no se pueden tener en cuenta a no ser que los servicios proporcionan información detallada. Por ejemplo la hora de llegada de un avión. Dependiendo del formato dado por los distintos proveedores, se puede evaluar la precisión de la hora de llegada. Por ejemplo, un servicio devuelve como resultado que el vuelo de ida que aterriza a las 8:35, pero no especifica si es am o pm ni la zona horaria. Para el trabajador de la agencia de viaje, que el avión llegue a las 8:35 AM CET u 8:35 AM PST puede ser irrelevante, pero para un usuario que necesita llegar a una reunión en la ciudad destino, conocer exactamente a qué hora llegará su vuelo es muy importante. Una forma de controlar este tipo de situaciones es exigiendo a los servicios que proporcionen unos datos con un nivel de precisión adecuados, si esa precisión no se observa entonces el servicio no está proporcionando unos datos con un nivel de calidad adecuado. De esta forma, TripPlanner puede informar al usuario sobre el margen de error que se puede encontrar, por ejemplo, con respecto a la hora de llegada. Proporcionar datos con un nivel adecuado de calidad puede ser de tal importancia para los servicios, que si no se cumple, pueden llegar a ser incluso excluidos en la búsqueda. Por ejemplo, si un proveedor de vuelo no incluye la información completa de la hora de aterrizaje (falta de precisión en los datos), entonces TripPlanner no debería tenerlo en cuenta para diseñar una solución global. 3.3 Aspectos tecnológicos XML y JAXB XML es el acrónimo de extensible Markup Language o Lenguaje de Marcas Extensible. XML es un lenguaje de marcas desarrollado por el World Wide Web Consortium (W3C) [17]. XML desempeña un importante papel en el intercambio de datos a través de la Web [17]. Es un estándar para la representanción de datos semi-estructurados.

47 CAPÍTULO 3. ESTADO DEL ARTE 25 Los datos XML se estructuran en forma de un árbol con elementos, y toda la estructura de árbol se denomina documento. Los datos dentro del árbol tienen un formato especial formado por etiquetas que ponen nombre a los datos y una posición en la estructura de árbol del documento. Una de sus ventajas más importante es que permite la compatibilidad entre sistemas y/o aplicaciones para intercambiar información. JAXB (del inglés Java Architecture for XML Binding) es un framework que proporciona un compilador de esquemas XML para crear clases Java a partir de un esquema XML concreto [40]. Además, permite el procesamiento y la obtención de documentos XML a partir de una jerarquía de objetos Java, y viceversa. El proceso de serialización es el proceso por el cual se obtiene el documento XML, y recibe el nombre de marshalling. El proceso inverso, de deserialización, recibe el nombre de unmarshalling. Para obtener la jerarquía de objetos Java que describen los elementos de los documentos XML, la forma recomendada es mediante la compilación del esquema XML, esto se realiza utilizando el compilador JAXB Binding xjc. En la Figura 3.8 se puede ver el proceso completo. Figura 3.8: JAXB: Java Architecture for XML Binding SOA y Servicios Web SOA (del inglés Service-Oriented Architecture), es una arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio [20]. La principal idea es ofrecer servicios para que sean consumidos por clientes de distintas aplicaciones y procesos de negocio. Por su parte, un Servicio Web es una tecnología concreta que utiliza

48 ASPECTOS TECNOLÓGICOS SOA para el intercambio de datos entre aplicaciones. Un Servicio Web puede comunicarse con procesos y funciones independientes o participar en un proceso de negocio complicado [22]. El propósito de los Servicios Web es que los sistemas se comuniquen entre sí utilizando tecnologías estándares de Internet; de este modo los sistemas que deban comunicarse con otros sistemas utilizan protocolos de comunicación y los formatos de datos que ambos comprenden. En [17] define los Servicios Web como "una aplicación software identificada por una URI, cuyas interfaces y enlaces son capaces de ser definidas, descritas y descubiertas como artefactos XML. Un Servicio Web soporta la interacción con otros agentes software mediante el intercambio de mensajes basado en XML a través de protocolos basados en Internet". En la Figura 3.9, muestra una interacción de un Servicio Web sencillo, donde se pueden ver los estándares que dan soporte a los Servicios Web [30]. Estos tres estándares, SOAP, WSDL y UDDI, se relacionan de la siguiente manera: una aplicación cliente de Servicios Web necesita un servicio web de otra aplicación. El cliente tiene que consultar el registro UDDI para el servicio, esto puede ser por nombre, categoría, identificador, etcétera. Una vez que lo localiza, el cliente obtiene la información sobre dónde se encuentra el documento WSDL desde el registro UDDI. Este WSDL contiene la información necesaria para utilizar el Servicio Web, entre otras cosas, contiene la información de como invocar al Servicio Web y el formato de los mensajes de petición en el esquema XML. Finalmente, el cliente crea un mensaje SOAP de acuerdo al esquema XML que se encuentra en el WSDL y envía la petición al servicio web [22]. DEFINICIÓN 6 SOAP (del inglés Simple Object Access Protocol), es un protocolo estándar que define los tipos y formatos de los mensajes XML que son intercambiados entre consumidor del servicio y el proveedor. DEFINICIÓN 7 WSDL (del inglés Web Services Description Language), es un lenguaje XML que permite describir los Servicios Web sintácticamente, es decir, define el contrato de servicios. En este contrato de servicios aparecen las operaciones del servicio disponibles, los mensajes de invocación/respuesta, puertos y protocolos de acceso, etcétera. DEFINICIÓN 8 UDDI (del inglés Universal Description, Discovery and Integration), define un marco que permite a las aplicaciones registrar y descubrir los Servicios Web desarrollados al público. Del mismo modo permite a las aplicaciones encontrar otros Servicios Web.

49 CAPÍTULO 3. ESTADO DEL ARTE 27 Figura 3.9: Relación entre los estándares que dan soporte a los Servicios Web. Imagen tomada y adaptada de [22].

50

51 Capítulo 4 Método de Trabajo En este capítulo se va a explicar cómo se ha usado el Proceso Unificado de Desarrollo (PUD) para lograr los objetivos descritos en el Capítulo 2. También se detalla el marco tecnológico sobre el cual se encuadra este PFC. 4.1 Breve Descripción de PUD En [26] se define el PUD como un marco de trabajo genérico que puede especializarse para un gran variedad de sistemas software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto. Para llevar a cabo el desarrollo de este PFC se ha usado el Proceso Unificado de Desarrollo, (en adelante PUD). Para ello, se ha dividido el desarrollo del PFC en diferentes etapas de una forma iterativa e incremental. La razón de esta decisión es que dada la generalidad del PUD se puede aplicar a casi cualquier tipo de proyecto, sin detrimento de otras alternativas, como las metodologías ágiles. Para diseñar y realizar todos los modelos de un sistema software, el PUD utiliza el Lenguaje Unificado de Modelado (en inglés Unified Modeling Language, UML). Por tanto, se han usado los tipos de diagramas UML más adecuados para describir los distintos modelos de este PFC. Las principales características del PUD son [26]: Dirigido por casos de uso. Los requisitos funcionales son las funcionalidades que un usuario espera de un sistema. Estos requisitos se representan mediante casos de uso. Los casos de uso guían el proceso de desarrollo del sistema y de la arquitectura de este. Centrado en la arquitectura. La arquitectura software determina el diseño del sistema, tanto en aspectos estáticos como dinámicos. Además la arquitectura está relaciona con los

52 BREVE DESCRIPCIÓN DE PUD casos de uso y permite el desarrollo de éstos. Iterativo e incremental. El PUD aplica la estrategia de "divide y vencerás", dividiendo el ciclo de vida del software en ciclos más pequeños que concluyen con una versión del producto completa (véase Figura 4.1). Cada uno de estos ciclos representa una iteración. Cada una de las iteraciones debe ser planificada de acuerdo a los flujos de trabajo: análisis, diseño, implementación y pruebas. Cada una de las iteraciones produce un incremento en la funcionalidad del sistema software que se está desarrollando. Figura 4.1: Ciclo de vida del PUD. Imagen adaptada de [26] Fases del desarrollo basado en PUD Como se decía anteriormente, el PUD divide el ciclo de vida de un producto software en ciclos, y cada uno concluye con una versión del mismo. Esta versión del producto es operativa y está preparada para su implantación y puesta en producción. Cada ciclo está compuesto de cuatro fases: Inicio, Elaboración, Construcción y Transición; a su vez éstas, se dividen en iteraciones que siguen los flujos de trabajos fundamentales: Requisitos, Análisis, Diseño, Implementación y Pruebas. A continuación se detallan cada una de las cuatro fases de las que se compone el ciclo de PUD.

53 CAPÍTULO 4. MÉTODO DE TRABAJO 31 Inicio En la fase de Inicio, se lleva a cabo una descripción del producto final que se quiere conseguir. Es decir, se estudia y determina el alcance del proyecto, su viabilidad, los riesgos potenciales y además se realiza la planificación del desarrollo del proyecto. En esta fase se obtienen los siguientes artefactos: Modelo inicial de casos de uso. Se han descrito las principales funcionalidades del sistema por lo que se describen mediante un diagrama de casos de uso. Boceto de la arquitectura del sistema y los subsistemas. Elaboración En esta fase se especifican con más detalle los casos de uso del producto desarrollados en la fase anterior y se profundiza en el diseño de la arquitectura del sistema. Después se estudian y desarrollan los casos de uso más críticos y se obtiene la línea base de la arquitectura. Al finalizar esta fase se tienen que conseguir los siguientes artefactos: Modelo de casos de uso mejorado. En el modelo de casos de uso en la fase de inicio se contemplan nuevos requisitos funcionales. Modelo de análisis. Se compone de los diagramas de clases de análisis y diagramas de comunicación. Modelo de diseño. Se compone de diagramas estáticos del sistema, por ejemplo diagramas de clases, y diagramas dinámicos del sistema, por ejemplo diagramas de interacción o secuencia. Arquitectura del sistema. Se realiza el diseño de las partes que constituyen el sistema. Construcción En la fase de Construcción se crea el producto software propiamente dicho. Aborda la mayor parte de la implementación de los requisitos funcionales del sistema. La línea base de la arquitectura evoluciona hasta convertirse en el sistema completo. Al finalizar esta fase el producto debería tener implementados todos los casos de uso. Los artefactos conseguidos en esta fase son: Modelo de diseño mejorado. Se refina el modelo de diseño de la fase anterior y se estudia el uso de patrones de diseño.

54 MARCO TECNOLÓGICO DE TRABAJO Modelo de implementación. Se realizan los diagramas de componentes y de despliegue, los cuales representan los elementos en la ejecución del sistema, sus relaciones y dónde se ejecutan. Modelo de pruebas. Contiene el conjunto de casos de pruebas unitarias que se realizan al finalizar cada una de las iteraciones de esta fase. Transición En esta fase, el producto pasa a ser un versión beta, es decir, se implanta, pero solo un número reducido de usuarios lo probará para así informar de posibles errores o deficiencias. Con la información de los usuarios que prueben el producto se realizarán mejoras o modificaciones si así fuera oportuno. Cuando esta fase finaliza se posee un versión del producto lista para ser entregada al cliente así como la documentación requerida. 4.2 Marco tecnológico de trabajo En esta sección se describen las herramientas y tecnologías que se han elegido para dar soporte al desarrollo de este PFC. Dichas herramientas y tecnologías son utilizadas tanto para el modelado del sistema y desarrollo de diagramas, como para la implementación del código y la documentación necesaria Herramientas para la Gestión de Proyectos Apache Subversion Apache Subversion [1] es un sistema de control de versiones. Ha sido utilizado a lo largo de todo el ciclo de vida de este PFC. Su uso ha permitido llevar un seguimiento del estado de los productos que son desarrollados y de sus cambios. En concreto, en este PFC, se ha utilizado un repositorio Subversion (SVN) alojado en el servidor QGP-Quivir Gestión de Proyectos. QGP, Quivir Gestión de Proyectos, es una aplicación de gestión de proyectos y gestión documental del grupo de investigación QUIVIR, de la Universidad de Sevilla con la que se colabora para la ejecución de este PFC. QGP está basado en Redmine. Redmine es una aplicación Web para la gestión de proyectos. Es multiplataforma y de código abierto. Las principales características de QGP son:

55 CAPÍTULO 4. MÉTODO DE TRABAJO 33 Soporta múltiples proyectos. Da soporte para diferentes roles. Gestión de planificación (diagrama de Gantt, calendario...). Gestión de archivos. Da soporte a la creación de Wikis. Notificaciones por correo electrónico. Integra administración de código fuente (Subversión, Git, Mercurial...) Maven Maven [2] es una herramienta de software para la gestión y construcción de proyectos basados en tecnologías Java creada por Jason van Zyl en el año Inicialmente estuvo integrado dentro del proyecto Jakarta pero ahora es un proyecto de Apache Software Foundation. Maven utiliza un Modelo de Objetos del Proyecto, (POM, acrónimo en inglés de Project Object Model), para especificar los aspectos de configuración del proyecto software a construir. Dicho modelo está basado en un formato XML (Ejemplo), que permite a Maven describir la construcción del proyecto, la generación de informes y documentación, gestión de dependencias, gestión de la configuración, versiones, distribución, etcétera. La arquitectura sobre la que se basa Maven es una arquitectura dinámica basada en plugins, los cuales son descargables de un repositorio central. De este modo se permite la reutilización para diferentes proyectos, cambiando simplemente los plugins que se utilizan y su configuración, manteniendo así patrones similares para diferentes proyectos. Esta herramienta ha sido utilizada para la gestión del proyecto y las dependencias con otros módulos y librerías en su versión Además, se ha utilizado el plugin llamado m2eclipse para la integración de Maven con Eclipse. En la sección se detalla el IDE elegido.

56 MARCO TECNOLÓGICO DE TRABAJO Herramientas para el modelado de software y la elaboración de la memoria Visual Paradigm for UML Visual Paradigm for UML es una herramienta CASE (Computer Aided Software Engineering o Ingeniería del Software Asistida por Computador) profesional diseñada para el modelado de UML, que soporta el ciclo de vida del desarrollo de un producto software. Ofrece un amplio conjunto de funcionalidades que permite crear los diferentes tipos de diagramas y además permite ingeniería inversa. Para el desarrollo de este PFC se ha utilizado esta herramienta en su versión 10.0 (licencia Enterprise), para realizar los modelos UML necesarios, tales como casos de uso, clases de análisis, clases de diseño, secuencia, interacción, despliegue, componentes, etcétera L A TEX L A TEX es un sistema de composición de textos, orientado para la creación de documentos científicos y técnicos y también a la elaboración de libros. Está formado por órdenes construidas con comandos del lenguaje TeX. L A TEX permite centrarse exclusivamente en el contenido del documento sin preocuparse de los detalles del formato del texto. La distribución utilizada en la elaboración de la memoria de este PFC ha sido TeXStudio [3]. TexStudio es una multiplataforma de código abierto que proporciona las herramientas necesarias para la composición y compilación de textos escritos en L A TEX. El compilador utilizado ha sido MiKTEX, versión BIBTEX BIBTEX es una herramienta que se utiliza para dar formato a las listas de referencias (bibliografía) de documentos generados con L A TEX. BIBTEX utiliza un archivo basado en texto para definir la lista de elementos bibliográficos, tales como artículos, libros, manuales, etcétera. Este archivo es de extensión.bib. En este documento se ha utilizado BIBTEX para dar formato a las referencias bibliográficas utilizadas.

57 CAPÍTULO 4. MÉTODO DE TRABAJO Herramientas y tecnologías para el desarrollo del proyecto Eclipse IDE Eclipse [4] es un IDE (Integrated Development Environment) compuesto por un conjunto de herramientas de programación. Es de código abierto, multiplataforma y es ampliable en cuanto a funcionalidades mediante la incorporación de plugins. En este PFC, el entorno de desarrollo utilizado para la construcción e implementación de la herramienta y sus diferentes componentes asociados utilizando el lenguaje Java, será Eclipse, version EE Juno. Además, se incorporará el plugin m2eclipse que proporciona un soporte integrado para Maven y el plugin Subversive que permite trabajar con el sistema de control de versiones Subversion Oracle 10g Oracle es un Sistema de Gestión de Base de Datos Relacional (SGBDR o en inglés RDBMS) desarrollado por Oracle Corporation [5]. Tiene las siguientes características: soporte de transacciones, estabilidad, escalabilidad y soporte multiplataforma. En este PFC se ha utilizado la versión Oracle 10 Express Edition SQL Developer SQL Developer es un entorno de desarrollo integrado para trabajar contra bases de datos Oracle. Está desarrollado por Oracle Corporation. En este PFC se utiliza SQL Developer en su versión VPN: Virtual Private Network Una VPN o red privada virtual (en inglés Virtual Private Network, VPN), es una tecnología de red que extiende de forma segura una red local sobre una red pública. Permite enviar y recibir datos sobre redes compartidas o públicas como si fuera una red privada. Esto es realizado estableciendo una conexión virtual punto a punto mediante el uso de conexiones dedicadas y/o encriptación. En este PFC se ha utilizado una VPN para poder realizar pruebas teniendo acceso a la base de datos.

58 MARCO TECNOLÓGICO DE TRABAJO JAXB: Java Architecture for XML Binding En la sección se describe esta tecnología en detalle. En este PFC, se ha utilizado en su versión 2.2.6, como un plugin incorporado al fichero de configuración de Maven. Los ficheros XML son utilizados para los distintos mensajes de datos maestros y para el fichero de configuración Axis2 y Apache Tomcat Axis2 es un contenedor de Servicios Web. Además de proporcionar la capacidad de agregar servicios web a las aplicaciones también funciona como servidor autónomo. Uno de los aspectos más destacables de Axis2 es el modelo de objetos (del inglés Axis Object Model, AXIOM). Este modelo es empleado para serializar y deserializar mensajes SOAP. Entre otras muchas características soporta el lenguaje de descripción de servicios web (del inglés Web Services Description Language, WDSL), lo que facilita la construcción de stubs para el acceso a servicios remotos. Los stubs 1 actúan como una puerta de entrada para los objetos del lado del cliente y como una puerta de salida a los objetos del lado del servidor. En este PFC, se ha utilizado Axis2 en su versión 1.6.2, para generar los servicios web, generar los stubs y para publicar los servicios web. Los Servicios Web generados con Axis2 se han desplegado en el servidor web Apache Tomcat. Apache Tomcat es un servidor web y un contenedor de servlets desarrollado por Apache Software Foundation (Apache es el servidor y Tomcat es el contenedor de aplicaciones). Es de código abierto [6] e implementa las especificaciones de los servlest y JSP (JavaServer Pages) de Sun Microsystems. Este servidor será empleado para el despliegue de los Servicios Web, en su versión Apache Tomcat Hibernate Hibernate [7] es un framework para el mapeo objeto-relacional (del inglés Object Relational- Mapping, ORM), utilizado en plataformas Java y de código abierto. 1 Los stubs son las clases que se encuentran en el cliente. Proporcionan los mecanismos para comunicarse con los Servicios Web.

59 CAPÍTULO 4. MÉTODO DE TRABAJO 37 Este framework permite mapear clases Java con tablas de una base de de datos relacional, mapeando así atributos entre la base de datos y el modelo de objetos de una aplicación. Esto es realizado mediante archivos en formato XML o anotaciones sobre los objetos. Hibernate ofrece también un lenguaje de consulta de datos, HQL (Hibernate Query Language). Las ventajas que ofrece este framework son muchas, entre las más destacables son que el desarrollador se abstrae del código necesario para la persistencia, proporciona total independencia del sistema gestor de base de datos y posee flexibilidad para adaptarse al esquema de tablas que se utilicen. Se ha utilizado Hibernate, en su versión 4.1.7, para llevar a cabo la gestión de la persistencia de los objetos de dominio que sean persistentes en el sistema JUnit JUnit es un framework desarrollado para la realización de pruebas unitarias para aplicaciones basadas en Java. Este framework es un conjunto de clases que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Se ha utilizado JUnit, en su versión 4.8.1, para ejecutar las pruebas del sistema. 4.3 Aplicación del PUD a este PFC En esta sección se muestra cómo se ha usado PUD para la gestión del desarrollo de los componentes de este PFC. Posteriormente, en el Capítulo 5, se detallarán los pasos seguidos y artefactos resultantes de cada una de las iteraciones que forman la planificación. Como resultado de este PFC se van a obtener dos productos diferentes (véase objetivos parciales en el Capítulo 2, sección 2.2) que se interrelacionan entre sí; por un lado la Arquitectura de Servicios I8K, y por otro lado una Interfaz de Programación de Aplicaciones, ICS-API, que se utilizará para que aplicaciones de terceros se puedan comunicar con la Arquitectura de Servicios (véase Figura 2.1). Se ha decidido usar una única instancia del PUD para desarrollar en paralelo ambos componentes. En la Tabla 4.1 se muestran los dos productos con sus correspondientes sistemas. Aunque tanto I8K como ICS-API tienen enfoques muy diferenciados, sin embargo las

60 APLICACIÓN DEL PUD A ESTE PFC Producto Sistemas Producto Sistemas I8K GestorI8K API ICS-API I8K.Cer110 I8K.110 I8K.Cer130 I8K.Ev130 I8K.Cer140 I8K.Ev140 Tabla 4.1: Productos a desarrollar. funcionalidades son transversales, por lo que para llevar a cabo el desarrollo del proyecto se han agrupado las funcionalidades similares en grupos funcionales para su mejor análisis (véase Tabla 4.2). En la Tabla 4.3 se muestra un resumen de la planificación de este PFC.

61 CAPÍTULO 4. MÉTODO DE TRABAJO 39 Grupo funcional GF1-Codificar GF2-Decodificar GF3-Evaluar y certificar en 130 GF4-Evaluar y certificar en 140 GF5-Añadir provenance Casos de Uso - ICS-API.CdU1 Definir configuración. - ICS-API.CdU3 Codificar. - GestorI8K.CdU1 Codificar Mensaje. - I8K.Cer110.CdU1 Codificar Mensaje. - I8K.110.CdU1 Codificar Mensaje. - I8K.110.CdU3 Comprobar Mensaje correcto sintácticamente. - ICS-API.CdU 4 Decodificar. - GestorI8K.CdU1 Gestionar Mensajes. - GestorI8K.CdU3 Decodificar Mensaje. - I8K.Cer110.CdU2 Decodificar Mensaje. - I8K.110.CdU2 Decodificar Mensaje. - ICS-API.CdU2 Configurar aspectos de certificación. - GestorI8K.CdU3 Certificar I8K.Cer130.CdU1 Evaluar Mensaje en I8K.Ev130.CdU1 Evaluar Mensaje en I8K.Cer130.CdU3 Añadir información de certificación GestorI8K.CdU3 Certificar I8K.Cer140.CdU1 Evaluar Mensaje en I8K.Ev140.CdU1 Evaluar Mensaje en I8K.Cer140.CdU3 Añadir información de certificación GestorI8K.CdU6 Actualizar provenance 2. - I8K.Cer110.CdU4 Actualizar provenance. - I8K.110.CdU4 Actualizar provenance. - I8K.Cer130.CdU2 Actulizar provenance. - I8K.Ev130.CdU2 Actualizar provenance. - I8K.Cer140.CdU2 Actualizar provenance - I8K.Ev140.CdU2 Actualizar provenance. Tabla 4.2: Grupos funcionales.

62 APLICACIÓN DEL PUD A ESTE PFC Fase Iteración Tareas Inicio Elaboración Preliminar Planificación del PFC, el estudio de los aspectos relevantes para el desarrollo del PFC, modelos de casos de uso y el documento Anteproyecto PFC. Búsqueda de nuevos requisitos funcionales, modelos de casos de uso, definición de arquitecturas de los sistemas. Vocabulario de soporte al Protocolo de Comunicación, modelo de datos maestros específicos para el dominio del TripPlanner (TripPlanner*) y de los proveedores y definición del Diccionario de Datos. Protocolos de comunicación, vocabulario específico que da soporte al Protocolo de comunicación e implementar una base de datos. 4 Desarrollo del grupo funcional GF1-Codificar. 5 Desarrollo del grupo funcional GF2-Decodificar. Construcción 6 Desarrollo del grupo funcional GF3-Evaluar y certificar en Desarrollo del grupo funcional GF4-Evaluar y certificar en Desarrollo del grupo funcional GF5-Añadir provenance. Transición 9 10 Integración de la Arquitectura de Servicios I8K y de ICS-API y pruebas de integración. Integración de la Arquitectura de Servicios I8K y de ICS-API con la aplicación TripPlanner y prueba final. 11 Documentación del PFC y del manual de usuario. Tabla 4.3: Plan de iteraciones.

63 Capítulo 5 Resultados En este capítulo se presentan los resultados obtenidos siguiendo el plan de trabajo presentado en la sección 4.3 para desarrollar todos los productos de este PFC. Se detalla el proceso de desarrollo que se ha seguido hasta la obtención de los dos productos que se obtienen en este proyecto, desde su fase de inicio hasta la fase de finalización, mostrando así su evolución iterativa e incremental. Como se describirá en la sección 5.1.3, el desarrollo de software se lleva a cabo en ciclos, donde cada ciclo está compuesto de cuatro fases: Inicio, Elaboración, Construcción y Transición. Dentro de cada una de estas fases se producen una o más iteraciones. Como se mencionó anteriormente, este PFC consta de dos productos, por lo que se ha decidido que en cada iteración se van a desarrollar ambos productos de forma paralela. Para hacer más fácil la lectura de la memoria de este PFC, en este capítulo se detallan aspectos generales y aquellos detalles (por ejemplo, fragmentos de código Java y XML) que se consideran muy importantes para la comprensión del trabajo que se presenta. No obstante, es posible encontrar todos los detalles del proyecto en el soporte físico adjunto a esta memoria, así como en la web alarcos.esi.uclm.es/i Fase de Inicio En esta fase de Inicio tiene lugar una única iteración, la preliminar. Esta fase se centra en el estudio del proyecto, la captura e identificación de requisitos y la realización un plan de iteraciones.

64 FASE DE INICIO Captura e identificación requisitos Para la identificación de los requisitos de los dos productos que conforman este PFC, se estudió la literatura mencionada en el Capítulo 3. Además, se llevó a cabo la identificación de las necesidades que los productos debían satisfacer y se trataron aspectos sobre el diseño. Tras la captura de estas necesidades, se pasó a elaborar una lista de requisitos funcionales y no funcionales que los productos deben cumplir para alcanzar los objetivos propuestos en el Capítulo Requisitos funcionales Los requisitos funcionales se van a agrupar en torno a los dos productos que conforman este PFC. Primero se van a enumerar los requisitos funcionales de la Arquitectura de Servicios I8K, y segundo los de ICS-API. I8K estará compuesta por diferentes agentes, donde cada agente es a su vez un sistema. Los agentes son necesarios para satisfacer los requisitos de las distintas partes del estándar ISO/IEC 8000: Cada uno tendrá los siguientes requisitos funcionales (RF): 1. Agente GestorI8K: gestiona las peticiones que se realizan a la Arquitectura I8K, delegando posteriormente en los correspondientes Agentes. I8K.GestorI8K.RF.01: Codificar Mensaje según ISO 8000: I8K.GestorI8K.RF.02: Decodificar Mensaje según ISO 8000: I8K.GestorI8K.RF.03: Certificar Nivel de Calidad de Datos en los datos del Mensaje de Datos Maestros según ISO 8000: I8K.GestorI8K.RF.04: Certificar Nivel de Calidad de Datos en los datos del Mensaje de Datos Maestros según ISO 8000: I8K.GestorI8K.RF.05: Adaptar formato de datos en los Mensaje entre proveedores y modelo de datos maestros (mapear). I8K.GestorI8K.RF.06 Actualizar información sobre el ciclo de vida de los datos del Mensaje de Datos Maestros (provenance). 2. Agente I8K.Cer110: se encarga de la gestión y mantenimiento del Diccionario de Datos. I8K. Cer110.RF.01: Codificar Mensaje de Datos Maestros.

65 CAPÍTULO 5. RESULTADOS 43 I8K. Cer110.RF.02 Decodificar Mensaje de Datos Maestros. I8K. Cer110.RF.03: Actualizar información sobre el ciclo de vida de los datos del Mensaje de Datos Maestros (provenance). 3. Agente I8K.110: se encarga de asegurar que el Mensaje de Datos Maestros está creado de acuerdo a la parte ISO 8000: Además codifica y decodifica el Mensaje de Datos Maestros. I8K.110.RF.01: Comprobar que el Mensaje de Datos Maestros es correcto sintácticamente. I8K.110.RF.02: Decodificar Mensaje de Datos Maestros. I8K.110.RF.03: Codificar Mensaje de Datos Maestros. I8K.110.RF.04: Actualizar información sobre el ciclo de vida de los datos del Mensaje de Datos Maestros (provenance). 4. Agente I8K.Mapeo: se encarga de realizar las conversiones de formato para los datos contenidos en el Mensaje de Datos Maestros desde el formato origen (proporcionado por los proveedores) al formato genérico de los Datos Maestros. I8K.Mapeo.RF.01: Transformar Mensaje de Datos Maestros a formato legible por los proveedores. I8K.Mapeo.RF.02: Transformar Mensaje a formato establecido para el intercambio de Mensajes de Datos Maestros. I8K.Mapeo.RF.03: Actualizar información sobre el ciclo de los datos del Mensaje de Datos Maestros (provenance). 5. Agente I8K.Cer130: añade información de certificación de la Precisión de los Datos Maestros del Mensaje de Datos Maestros. I8K.Cer130.RF.01: Solicitar evaluación de la Precisión. I8K.Cer130.RF.02: Añadir información de certificación de la Precisión del Mensaje de Datos Maestros. I8K.Cer130.RF.03: Actualizar información sobre el ciclo de vida de los datos del Mensaje de Datos Maestros (provenance). 6. Agente I8K.Cer140: añade información de certificación de la Compleción de los Datos Maestros del Mensaje de Datos Maestros.

66 FASE DE INICIO I8K.Cer140.RF.01: Solicitar evaluación de la Compleción. I8K.Cer140.RF.02: Añadir información de certificación de la Compleción del Mensaje de Datos Maestros. I8K.Cer140.RF.03: Actualizar información sobre el ciclo de vida de los datos del Mensaje de Datos Maestros (provenance). 7. Agente I8K.Ev130: evalúa la Precisión de los Datos Maestros del Mensaje de Datos Maestros. I8K.Ev130.RF.01: Evaluar la Precisión de los datos del Mensaje de Datos Maestros. I8K.Ev130.RF.02: Actualizar información sobre el ciclo de vida de los datos del Mensaje de Datos Maestros (provenance). 8. Agente I8K.Ev140: evalúa la Compleción de los Datos Maestros del Mensaje de Datos Maestros I8K.Ev140.RF.01: Evaluar la Compleción de los datos del Mensaje de Datos Maestros. I8K.Ev140.RF.02: Actualizar información sobre el ciclo de vida de los datos del Mensaje de Datos Maestros (provenance). Con estos ocho agentes se da soporte a la implementación de las partes 100, 102, 110, 120, 130 y 140 del estándar ISO/IEC 8000:2009. Tal como se detalló en el Capítulo 3, estos agentes proponen usar un formato para el intercambio de Mensajes de Datos Maestros entre aplicaciones y especifican los requisitos que deben cumplir dichos mensajes para incorporar información sobre el nivel de Calidad de los Datos contenidos en el Mensaje de Datos Maestros, respecto a las dimensiones de calidad de Precisión y Compleción. Por su parte, ICS-API tendrá los siguientes requisitos funcionales: ICS-API.RF.01 Configurar la información sobre la organización. ICS-API.RF.02 Configurar los aspectos sobre certificación deseados. ICS-API.RF.03 Dar soporte para realizar la comunicación con I8K para codificar mensajes. ICS-API.RF.04 Dar soporte para realizar la comunicación con I8K para decodificar mensajes. ICS-API.RF.05 Gestionar la petición de certificación del nivel de calidad de los datos contenidos en un Mensaje de Datos Maestros.

67 CAPÍTULO 5. RESULTADOS Requisitos no funcionales A continuación se enumeran los requisitos no funcionales: Los diferentes agentes que conforman la Arquitectura de Servicios tienen que utilizar el vocabulario común de Gestión de Datos Maestros. Las aplicaciones de terceros (como TripPlanner -de ahora en adelante TripPlanner*, o proveedores) se comunicarán con I8K a través de ICS-API. ICS-API sólo puede comunicarse con I8K mediante Servicios Web, descritos mediante su correspondientes WSDL. La comunicación entre los distintos agentes usará el protocolo de comunicaciones desarrollado a tal efecto. Este protocolo se implementará mediante Servicios Web descritos mediante sus correspondientes WSDL. Como se ha explicado en el Capítulo 4, en la sección 4.3, se han agrupado las funcionaliades similares de I8K e ICS-API en grupos funcionales para conseguir un mejor análisis Modelo de Casos de Uso para cada Sistema Realizada la identificación de requisitos funcionales de I8K e ICS-API, se procede a realizar una versión inicial del modelo de casos de uso. En la fase de Inicio los diagramas de casos de uso van a ser modelados en un alto nivel de abstracción. En las iteraciones de la fase de Elaboración, se añadirán más detalles a los diagramas de casos de uso. En la Figura 5.1 se observa el diagrama de casos de uso del agente GestorI8K. En este diagrama se puede ver como el GestorI8K, que es el encargado de recepcionar y procesar en primera instancia las peticiones que se realizan a la Arquitectura de Servicios I8K desde las aplicaciones que necesitan certificar sus datos. Hace de proxy a la arquitectura y delega las diferentes responsabilidades en los distintos agentes (que a su vez son otros sistemas que se desarrollarán en paralelo). En la Figura 5.2 se muestra el diagrama de caso de usos del agente I8K.110. En la Figura 5.3 se observa el diagrama de caso de usos de ICS-API. Las aplicaciones que pueden utilizar ICS-API son la aplicación TripPlanner* y los proveedores de datos.

68 FASE DE INICIO Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> GestorI8K <<Include>> CdU2 Codificar mensaje <<Include>> <<system>> I8K.Cer110 <<Include>> CdU3 Decodificar mensaje <<Include>> Aplicación CdU1 Gestionar mensajes <<Include>> CdU6 Mapear mensaje <<Include>> CdU7 Actualizar provenance <<system>> I8K.Mapeo <<Include>> CdU4 Certificar 130 <<Include>> Cliente Proveedor <<Include>> CdU5 Certificar 140 <<Include>> <<system>> I8K.Cer130 TripPlanner* <<system>> I8K.Cer140 Figura 5.1: Modelo de caso de usos del Agente GestorI8K. Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> I8K.110 CdU1 Codificar mensaje <<Include>> <<Include>> CdU4 Actualizar provenance <<system>> I8K.Cer110 CdU3 Comprobar mensaje sintácticamente CdU2 Decodificar mensaje <<Include>> <<system>> DD Figura 5.2: Modelo de caso de usos del Agente I8K.110. Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) ICS-API Usuario CdU3.1 Añadir terminos CdU3.2 Añadir terminos 130 Proveedor TripPlanner* <<Extend>> CdU3.3.1 Añadir patrones CdU3.3 Añadir terminos 140 extension points CdU3.3.1 CdU3.3.2 Añadir fuentes CdU3.3.2 Añadir fuentes <<Extend>> Figura 5.3: Modelo de caso de usos de ICS-API.

69 CAPÍTULO 5. RESULTADOS Plan de iteraciones En esta fase se ha realizado una planificación basada en la metodología PUD propuesta que se muestra en la sección 4.3. A continuación para cada una de la iteraciones planificadas se ha realizado una tabla donde se detallan los objetivos y artefactos que se quieren conseguir (Tablas ). Iteración Fase a la que pertenece Objetivos Artefactos Preliminar Inicio - Estudiar los conceptos necesarios sobre datos maestros, MDM e ISO/IEC 8000: Estudiar conceptos sobre la herramienta usada para el ejemplo de aplicacion: TripPlanner. - Realizar los modelos de casos de uso de I8K e ICS-API. - Realizar el documento Anteproyecto PFC. - Estudio del proyecto y justificación de si el desarrollo es viable. - Modelo general de casos de uso para I8K. - Modelo general de casos de uso para ICS-API. - Documento Anteproyecto del PFC. Tabla 5.1: Iteración preliminar Iteración 1 Fase a la que pertenece Objetivos Artefactos Elaboración - Realizar un estudio para encontrar nuevos requisitos funcionales. - Realizar los modelos de casos de uso con las mejoras. - Definir la arquitectura de I8K. - Definir la arquitectura de ICS-API. - Modelo de casos de uso para I8K. - Modelo de casos de uso para ICS-API. - Diseño de la arquitectura. Tabla 5.2: Iteración 1

70 FASE DE INICIO Iteración 2 Fase a la que pertenece Objetivos Artefactos Elaboración - Diseñar y definir el vocabulario de soporte al Protocolo de Comunicación. - Diseñar y definir el modelo de datos maestros específicos para el dominio del Organizador de viaje. - Diseñar y definir una base de datos donde se almacenará el Diccionario de Datos, elemento fundamental de la arquitectura I8K. - Vocabulario específico de soporte al Protocolo de Comunicación de Mensajes de Datos Maestros. - Modelo de Datos Maestros específico para el dominio del Organizador de Viajes. - Diseño de la base de datos para el Diccionario de Datos. Tabla 5.3: Iteración 2 Iteración 3 Fase a la que pertenece Objetivos Artefactos Elaboración - Diseñar y definir los protocolos de comunicación, uno para el intercambio de mensajes, y el otro para el intercambio de mensajes entre los Agentes. - Diseñar e implementar el vocabulario específico que da soporte al Protocolo de comunicación. - Implementar una base de datos de acuerdo al modelo de datos maestros obtenido de la iteración anterior. - Protocolo de Comunicación para el intercambio de Mensajes de Datos Maestros entre las aplicaciones y la arquitectura de servicios. - Protocolo de Comunicación para el intercambio de Mensajes de Datos Maestros entre los Agentes. - Esquema de la estructura de los Mensajes de Datos Maestros. - Bases de datos que alberga el Diccionario de Datos. Tabla 5.4: Iteración 3

71 CAPÍTULO 5. RESULTADOS 49 Iteración 4 Fase a la que pertenece Objetivos Artefactos Construcción - Realizar el análisis, diseño, implementación y pruebas de los casos de uso del Grupo Funcional 1 (GF1-Codificar). - Modelo de Análisis y de Diseño de I8K, correspondiente al Grupo Funcional 1 (GF1-Codificar). - Modelo de Análisis y de Diseño de ICS-API, correspondiente al Grupo Funcional 1 (GF1-Codificar). Tabla 5.5: Iteración 4 Iteración 5 Fase a la que pertenece Objetivos Artefactos Construcción - Realizar el análisis, diseño, implementación y pruebas de los casos de uso del Grupo Funcional 2 (GF2-Decodificar). - Modelo de análisis y diseño de I8K, correspondiente al Grupo Funcional 2 (GF2-Decodificar). - Modelo de Análisis y de Diseño de ICS-API, correspondiente al Grupo Funcional 2 (GF2-Decodificar). Tabla 5.6: Iteración 5 Iteración 6 Fase a la que pertenece Objetivos Artefactos Construcción - Realizar el análisis, diseño e implementación de los casos de uso del Grupo Funcional 3 (GF3-Evaluar y certificar en 130). - Modelo de análisis y diseño de I8K, correspondiente al Grupo Funcional 3 (GF3-Evaluar y certificar en 130). Tabla 5.7: Iteración 6

72 FASE DE INICIO Iteración 7 Fase a la que pertenece Objetivos Artefactos Construcción - Realizar el análisis, diseño e implementación de los casos de uso del Grupo Funcional 4 (GF4-Evaluar y certificar en 140). - Modelo de análisis y diseño de I8K, correspondiente al Grupo Funcional 4 (GF4-Evaluar y certificar en 140). Tabla 5.8: Iteración 7 Iteración 8 Fase a la que pertenece Objetivos Artefactos Construcción - Realizar el análisis, diseño e implementación de los casos de uso del Grupo Funcional 5 (GF5-Añadir provenance). - Modelo de análisis y diseño de I8K, correspondiente al Grupo Funcional 5 (GF5-Añadir provenance). Tabla 5.9: Iteración 8 Iteración 9 Fase a la que pertenece Objetivos Artefactos Transición - Lograr la integración de la Arquitectura de Servicios I8K y de ICS-API. - Crear de pruebas de integración. - Pruebas integración. Tabla 5.10: Iteración 9 Iteración 10 Fase a la que pertenece Objetivos Artefactos Transición - Integrar la Arquitectura de Servicios I8K y de ICS-API con la aplicación TripPlanner (TripPlanner*). - Obtener los resultados finales de las pruebas de integración. - Pruebas finales. Tabla 5.11: Iteración 10

73 CAPÍTULO 5. RESULTADOS 51 Iteración 11 Fase a la que pertenece Objetivos Artefactos Transición - Realizar de la documentación el PFC. - Realizar del manual de usuario. - Memoria del PFC. - Manual de usuario. Tabla 5.12: Iteración 11

74 FASE DE ELABORACIÓN 5.2 Fase de Elaboración La fase de Elaboración consta de tres iteraciones que se centran fundamentalmente en el análisis y diseño de I8K e ICS-API. La primera de ellas se centra de nuevo en la captura de requisitos, en el análisis y en algunas tareas de diseño, como la definición de la arquitectura de los dos sistemas. La segunda y tercera iteración se centran en tareas de diseño y de implementación Iteración 1 En esta iteración (véase Tabla 5.2), se realiza un estudio más detallado del problema para identificar nuevos requisitos funcionales, se realizan los modelos de casos de uso definitivos para I8K e ICS-API y se define la arquitectura de los dos productos. Cada uno de los sistemas o agentes de I8K tendrá una arquitectura similar basada en Servicios Web. Identificación de requisitos Al finalizar la iteración de la fase anterior, se ha obtenido un primer modelo de casos de uso con los requisitos funcionales identificados. Se revisó dicho modelo y el plan de iteraciones realizado para así poder identificar nuevos requisitos funcionales, si los hubiera, o eliminar alguno no necesario. Al finalizar la revisión, como resultado, se obtuvieron las siguientes conclusiones: El requisito funcional ICS-API.RF.03 Dar soporte para realizar la comunicación con I8K para codificar mensajes se va a descomponer en tres subrequisitos: ICS-API.RF.03.1 Añadir los términos (datos) que las aplicaciones desean codificar. ICS-API.RF.03.2 Añadir información para evaluar el nivel de precisión (parte 130 del estándar). ICS-API.RF.03.3 Añadir información para evaluar el nivel de compleción (parte 140 del estándar). Se estudió a fondo la funcionalidad que debería tener el agente I8K.Mapeo, y se llegó al acuerdo de que este agente no se va a desarrollar en el presente PFC por que el alcance del proyecto quedaría temporalmente fuera de este proyecto fin de carrera.

75 CAPÍTULO 5. RESULTADOS 53 Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> GestorI8K CdU1 Gestionar mensajes <<Include>> CdU2 Codificar mensaje <<Include>> <<system>> I8K.Cer110 Cliente Aplicación CdU3 Decodificar mensaje CdU7 Actualizar provenance <<Include>> <<Include>> CdU4 Certificar 130 TripPlanner* Proveedor CdU5 Certificar 140 <<Include>> <<system>> I8K.Cer130 <<system>> I8K.Cer140 Figura 5.4: Diagrama de caso de usos del Agente GestorI8K. Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> I8KCer.110 CdU1 Codificar mensaje <<Include>> <<Include>> CdU4 Actualizar provenance <<system>> I8K.110 CdU2 Decodificar mensaje <<system>> GestorI8K CdU3 Mapear mensaje <<Include>> <<system>> I8K.Mapeo Figura 5.5: Diagrama caso de usos del Agente I8K.Cer110. Modelos de casos de uso para I8K A continuación se muestran los modelos de caso de uso para los diferentes agentes que forman la Arquitectura I8K (Figura 5.4 a 5.10). Donde se pueden observar las diferentes funcionalidades de cada uno de ellos.

76 FASE DE ELABORACIÓN Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> I8K.110 CdU1 Codificar mensaje <<Include>> <<Include>> CdU4 Actualizar provenance <<system>> I8K.Cer110 CdU3 Comprobar mensaje sintácticamente CdU2 Decodificar mensaje <<Include>> <<system>> DD Figura 5.6: Diagrama caso de usos del Agente I8K.110. Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> I8K.Cer130 CdU1 Evaluar mensaje en 130 <<system>> GestorI8K <<Include>> <<system>> I8K.Ev130 CdU2 Añadir información de certificación en 130 <<Include>> CdU3 Actualizar provenance Figura 5.7: Diagrama caso de usos del Agente I8K.Cer130. Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> I8K.Cer140 CdU1 Evaluar mensaje en 140 <<system>> GestorI8K <<Include>> <<system>> I8K.Ev140 CdU2 Añadir información de certificación en 140 <<Include>> CdU3 Actualizar provenance Figura 5.8: Diagrama caso de usos del Agente I8K.Cer140.

77 CAPÍTULO 5. RESULTADOS 55 Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> I8K.Ev130 CdU1 Evaluar mensaje en 130 <<system>> I8K.Cer130 <<Include>> CdU2 Actualizar provenance Figura 5.9: Diagrama caso de usos del Agente I8K.Ev130. Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> I8K.Ev140 CdU1 Evaluar mensaje en 140 <<system>> I8K.Cer140 <<Include>> CdU2 Actualizar provenance Figura 5.10: Diagrama caso de usos del Agente I8K.Ev140.

78 FASE DE ELABORACIÓN Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) ICS-API Usuario CdU3.1 Añadir terminos CdU3.2 Añadir terminos 130 Proveedor TripPlanner* <<Extend>> CdU3.3.1 Añadir patrones CdU3.3 Añadir terminos 140 extension points CdU3.3.1 CdU3.3.2 Añadir fuentes CdU3.3.2 Añadir fuentes <<Extend>> Figura 5.11: Diagrama de caso de usos de ICS-API.CdU3 Codificar. Modelos de casos de uso para ICS-API En la Figura 5.11 se muestra el modelo de caso de uso asociado al caso de uso ICS-API.CdU3 Codificar. Diseño de la arquitectura del producto I8K - Arquitectura cliente-servidor La arquitectura de este PFC es una arquitectura basada en cliente-servidor orientada al procesamiento de mensajes. Las aplicaciones de terceros son las aplicaciones clientes, las cuales utilizan ICS-API para comunicarse con la Arquitectura de Servicios I8K. I8K es el servidor que procesa las peticiones enviadas por las aplicaciones. Por otro lado la Arquitectura de Servicios I8K está formada por Servicios Web. Esto significa que los distintos agentes que conforman dicha arquitectura implementan Servicios Web. - Arquitectura de I8K La Arquitectura de Servicios I8K está formada por ocho agentes que intercambian mensajes. Estos agentes permiten: 1. Codificar/Decodificar los mensajes de acuerdo al modelo de datos. 2. Evaluar el nivel de calidad de las dimensiones de precisión y compleción. 3. Certificar el nivel de calidad de los datos maestros contenidos en los mensajes. Dichos mensajes serán intercambiados entre las aplicaciones que necesiten añadir información sobre el nivel de calidad de datos.

79 CAPÍTULO 5. RESULTADOS 57 A continuación se detallan las responsabilidades específicas de cada uno de los diferentes agentes: GestorI8K: este agente es el encargado de recepcionar y procesar, en primera instancia, las peticiones que se realizan a la Arquitectura de Servicios I8K desde las aplicaciones que necesitan codificar, decodificar y/o certificar sus datos. Hace de fachada a la arquitectura y delega la ejecución de las responsabilidades en los distintos agentes. I8K.Cer110: se encarga de la gestión y mantenimiento del Diccionario de Datos que requiere la parte 110. I8K110: se encarga de codificar y decodificar los distintos Mesajes de Datos Maestros con respecto al modelo de datos que se ha creado de acuerdo a los requisitos específicos de la parte 110 del estándar. I8K.Ev130: es el encargado de evaluar la Precisión de los datos maestros contenidos en el Mensaje de Datos Maestros. I8K.Cer130: es el encargado de añadir la información de certificación del nivel de Precisión de los datos maestros contenidos en elmesajes de Datos Maestros según especifican los requisitos de la parte 130 del estándar. Este agente solicita la evaluación de la precisión al agente I8K.Ev130. I8K.Ev140: es el encargado de evaluar la Compleción de los datos maestros contenidos en el Mensaje de Datos Maestros. I8K.Cer140: es el encargado de añadir la información de certificación del nivel de Compleción de los datos maestros contenidos en el Mensaje de Datos Maestros según especifican los requisitos de la parte 140 del estándar. Este agente solicita la evaluación de la compleción al agente I8K.Ev130. Además, todos los agentes añaden información sobre el ciclo de vida de los datos (data provenance) según los requisitos mostrados en ISO/IEC Por tanto, los Mensaje de Datos Maestros que se intercambien las aplicaciones cumplen así el estándar ISO/IEC 8000:2009. En la Figura 5.12 se muestra un modelo de despliegue de la arquitectura.

80 FASE DE ELABORACIÓN Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) Database Server I8K.110 Data Dictionary I8K.Cer110 BD_Mapeo GestorI8K I8K.Mapeo I8K.Cer130 I8K.Ev130 I8K.Cer140 I8K.Ev140 Figura 5.12: Modelo de despliegue de la Arquitectura de Servicios I8K Iteración 2 A finalizar la iteración anterior, se revisaron los modelos de casos de uso y los artefactos obtenidos. Ya no se identificaron nuevos requisitos, por lo que en esta y en las sucesivas iteraciones se comenzarán a definir los vocabularios, protocolos de comunicación y modelos de datos necesarios para el desarrollo de los diferentes sistemas. En esta iteración (véase Tabla 5.3) se aborda el diseño y definición de un vocabulario de soporte al Protocolo de Comunicación, de un modelo de datos maestros específicos para el dominio del Organizador de viaje y de la base de datos que almacenará el Diccionario de Datos. Vocabulario de soporte al Protocolo de comunicación Como parte de la implementación del Protocolo de comunicación los Mensaje de Datos Maestros están estructurados en diferentes partes. Dichas partes son: Cabecera, cuya implementación en XML dará lugar al elemento <head>. Puede contener a su vez la siguiente información: - type-message: especifica el tipo de mensaje. - syntax: especifica la información sobre la sintaxis que cumple el mensaje de datos maestros. - cert130: donde se especifica si se desea certificar (certificated130) los datos de acuerdo a la precisión, el nivel mínimo requerido (requiredlevelthreshold130), y el nivel proporcionado por el proveedor (certifiedmeasuredlevel130).

81 CAPÍTULO 5. RESULTADOS 59 - cert140: donde se especifica si se desea certificar (certificated140) los datos de acuerdo a la compleción, el nivel mínimo requerido (requiredlevelthreshold140) y el nivel proporcionado por el proveedor (certifiedmeasuredlevel140). Cuerpo, que contiene los datos que se intercambiarán entre aplicaciones. Dará lugar a un elemento <data>. Esta parte está compuesta por los términos (datos maestros) que contiene el mensaje, con sus respectivos valores. Contendrá los siguientes atributos: -property-value property-ref El valor se especifica por: -controlled-value value-ref Reglas de calidad de datos, dará lugar a <data-quality-rules>. En esta parte se especifican las reglas de calidad de datos para que I8K pueda efectuar las operaciones de evaluación y certificación de los niveles de calidad. Las reglas para la precisión se establecerán dentro del atributo cert130, y las reglas para la compleción dentro de cert140. cert130 está compuesta por: - term: es el dato maestro sobre el que se indica la regla. - pattern: un patrón (expresión regular) que debe cumplir el valor que proporcione el proveedor para el dato maestro. - source: fuente de información donde se puede consultar si el valor proporcionado por el proyeedor de datos es correcto. - required: indica si es obligatorio que el término tenga valor. cert140 está formado por: -term: es el dato maestro sobre el que se indica la regla. -dqproperty: su valor es required, he indica si es obligatorio que el término tenga valor. Información de procedencia, dará lugar a <provenance>. Esta parte contiene la información sobre el ciclo de vida del término. Y está formado por los siguientes atributos: -date: hora y fecha en la que se tiene el mensaje de datos maestros. -event-type: tipo de acción que se realiza sobre el mensaje (toma el valor de encode o decode). -organization-ref : organización que realiza la operación sobre el Mensaje de Datos Maestros.

82 FASE DE ELABORACIÓN -person-ref : organización/aplicación que envía el mensaje. -person-destination: organización/aplicación destinataria del mensaje. Información de certificación de la precisión, representada por <accuracy-event>. En esta parte se describe la información de certificación de la precisión de los datos contenidos en el Mensaje de Datos Maestros. Información de certificación de la compleción, representada por <completeness-event>. En esta parte se describe la información de certificación de la precisión de los datos contenidos en el Mensaje de Datos Maestros. Tanto accuracy-event como completeness-event contienen la misma información; date, organization-ref y event-type (toma el valor certify130 o certify140 respectivamente), donde sus valores definen lo mismo que lo comentado anteriormente en provenance. Diseño de la base de datos que almacena el Diccionario de Datos Como se detalló en el Capítulo 3, el estándar ISO/IEC 8000: requiere la existencia de un Diccionario de Datos donde se encuentren almacenados todos los términos, llamados también datos maestros, para que la Arquitectura de Servicios I8K pueda llevar a cabo la codificación y decodificación semántica de los datos maestros contenidos en los diferentes Mensaje de Datos Maestros; estos mensajes son intercambiados entre las aplicaciones. Se ha diseñado un Modelo de Datos para la definición del Diccionario de Datos (DD). El modelo de datos consta de los siguientes elementos: Término: este campo permite especificar los términos que se incluyen en el vocabulario, es decir su valor en texto. Por ejemplo FROM_LOCATION. Estado: representa si un término está activo o no dentro del DD. Idioma: especifica el idioma en el que el término está en el DD. El mismo término puede estar almacenado en diferentes idiomas. Organización: es la información de la organización que ha introducido el término en el DD. Definición: definición del término. Si el término está almacenado en varios idiomas, éste tendrá las correspondientes definiciones en los idiomas.

83 CAPÍTULO 5. RESULTADOS 61 Identificador: este campo contiene el valor del término codificado. Por tanto cuando un Mensaje de Datos Maestros sea codificado el valor del campo Término se sustituirá por el valor de este campo. Para los identificadores del DD para los distintos términos se va a utilizar la estructura: organizacion#dato#version = nnnnxxxx#yyzzzzzz#m Utilizando los estándares: - ISO 6523 para identificar a las organizaciones: nnnnxxxx siendo nnnn código internacional del propietario y xxxx el identificador de la organización. - ISO para identificar el dato: yyzzzzzz siendo yy el código de identificación del espacio, zzzzzz el código del ítem. - ISO para identificar m, que es la versión del identificador del dato (yyzzzzzz). Nombre de la organización: nombre de la organización que almacena el término. Además de almacenar la información referente a cada dato maestro (término), también es necesario almacenar la información de la sintaxis formal que cumplen los Mensaje de Datos Maestros. Teniendo en cuenta los aspectos necesarios del modelo de datos mencionados anteriormente, se diseñan las clases de dominio persistentes y sus relaciones para modelar y diseñar la base de datos que hace que los objetos del dominio puedan ser persistentes (Figura 5.13). El patrón de persistencia que se ha usado ha sido el patrón 1 clase, 1 tabla, donde se construye una tabla por cada clase en el diagrama de clases. En la Figura 5.14 se muestra el diagrama entidad-relacional de la base de datos donde está almacenado el DD. Datos maestros específicos para el dominio del TripPlanner* Para la validar los resultados de este PFC como se ha mencionado anteriormente, se ha elegido el caso de estudio de una aplicación llamada TripPlanner*. El objetivo de dicha aplicación consiste en organizar un viaje compuesto por hotel, avión y alquiler de coche. Hotel, avión y alquiler de coche son tipo de proveedores de datos a los que TripPlanner* solicita datos que son intercambiados mediante un Mensaje de Datos Maestros. Como se ha mencionado en el Capítulo 3 y en la sección anterior (véase sección 5.2.2), uno de los requisitos de ISO/IEC 8000: es la implementación de un diccionario de datos que contenga los términos específicos del dominio. Por tanto para validar los resultados del PFC con TripPlanner* es

84 FASE DE ELABORACIÓN Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<ORM Persistable>> Syntax -syntaxid : int -name : String -version : String -url_xsd : String termterm 0..* {unique} 0..* {unique} term <<ORM Persistable>> termtermid2 Term -termid : String -term : String -identifierid : String -organizationname : String 0..* {unique} 0..* {unique} 0..* term {unique} term term 0..* {unique} organization 0..1 {unique} -statusid : int -value : String status <<ORM Persistable>> Status 1 {unique} <<ORM Persistable>> Organization -organizationid : String -name : String -phonenumber : Long -address : String - String -description : String 1 {unique} status 0..1 {unique} organization 0..* {unique} definition language 1 {unique} definition 1 {unique} -languageid : String -value : String 0..* {unique} 0..* {unique} definition <<ORM Persistable>> Definition -definitionid : String -description : String -externalreference : String -organizationname : String <<ORM Persistable>> Language 1 {unique} language definition Figura 5.13: Diagrama de clases de domino de alto nivel. Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) syntax syntaxid integer(10) name varchar(255) version varchar(255) url_xsd varchar(255) statusid value Status integer(10) varchar(255) term termid varchar(255) term varchar(255) status integer(10) language varchar(255) organization varchar(255) definition varchar(255) identifierid varchar(255) organizationname varchar(255) organization organizationid varchar(255) name varchar(255) phonenumber bigint(13) address varchar(255) varchar(255) description varchar(255) definition definitionid varchar(255) description varchar(1000) externalreference varchar(255) organization varchar(255) status integer(10) language varchar(255) organizationname varchar(255) term_term termtermid varchar(255) termtermid2 varchar(255) language languageid varchar(255) value varchar(255) Figura 5.14: Diagrama entidad-relacional de la base de datos que alberga el Diccionario de Datos.

85 CAPÍTULO 5. RESULTADOS 63 necesario un Diccionario de Datos donde estén almacenados todos los términos específicos del dominio de los viajes. Se han realizado estudios para determinar cuáles son los términos que tanto TripPlanner* como los diferentes proveedores intercambiarían en sus mensajes para que la aplicación pueda llevar a cabo su cometido. Estos términos tienen que estar almacenados en el Diccionario de Datos para que sea posible que una de las aplicaciones (TripPlanner* o un proveedor) pueda codificar o decodificar un mensaje. Además de identificar todos los términos, también se realizó un estudio de aquellos términos que para la aplicación TripPlanner* reciben un nombre y para los proveedores reciben otro nombre. Por ejemplo, para TripPlanner* el término FROM_LOCATION significa la ciudad destino desde donde partirá el cliente y para el proveedor de viajes, que proporciona los alquileres de coche, este término recibe el nombre de PICK_UP_LOCATION; por tanto es necesario conocer este mapeo para poder realizar la codificación y decodificación semántica correctamente. En el Anexo A se encuentran algunos de estos términos específicos del dominio de viajes utilizados para el desarrollo de este PFC Iteración 3 En esta iteración (véase Tabla 5.4) se diseñan y definen los Protocolos de comunicación necesarios para el intercambio de mensajes; uno para el intercambio de éstos y otro para el intercambio de mensajes entre los diferentes agentes. Además se diseña e implementa el vocabulario definido en la iteración anterior que da soporte al Protocolo de comunicación. Por último se implementa una base de datos que albergará el Diccionario de Datos, de acuerdo al diseño de la iteración anterior. Protocolos de comunicación para el intercambio de mensajes Para describir el funcionamiento de la Arquitectura de Servicios I8K es necesario un protocolo de comunicación. Este protocolo regula el intercambio de mensajes entre las aplicaciones e I8K. Despendiendo del fin para el que se desee el mensaje, éste será de un tipo u otro. En la Tabla 5.13 se detallan los tipos de Mensaje de Datos Maestros que se intercambian entre las aplicaciones y la Arquitectura de Servicios I8K.

86 FASE DE ELABORACIÓN Tipo I8K.COD-GE I8K.CODED I8K.DEC I8K.DECODED I8K.COD-CR130 I8K.COD-CR140 I8K.COD-CR Descripción Una aplicación necesita codificar un Mensaje de Datos Maestros. I8K ha codificado un Mensaje de Datos Maestros. Una aplicación necesita decodificar un Mensaje de Datos Maestros para poder entender su contenido. I8K ha decodificado un Mensaje de Datos Maestros. Una aplicación necesita codificar el mensaje y evaluar y certificar los datos maestros que contiene dicho mensaje de acuerdo al nivel de calidad de precisión. Una aplicación necesita codificar el mensaje y evaluar y certificar los datos maestros que contiene dicho mensaje de acuerdo al nivel de calidad de compleción. Una aplicación necesita codificar el Mensaje de Datos Maestros, y evaluar y certificar los datos maestros que contiene dicho mensaje de acuerdo a los niveles de precisión y compleción. Tabla 5.13: Tipos de mensajes de datos maestros intercambiados entre las aplicaciones e I8K. Tipo I8K.REQ I8K.RES Descripción Una aplicación envía un mensaje de petición de datos a un proveedor de datos. Un proveedor de datos envía un mensaje de respuesta con los datos maestros solicitados por otra aplicación. Tabla 5.14: Tipos de mensajes de datos maestros enviados entre una aplicación y un proveedor de datos. Los tipos de mensajes de datos maestros que se intercambian entre las aplicaciones se muestran en la Tabla Los pasos que una aplicación debe seguir para enviar una solicitud de datos a un proveedor se reflejan en el modelo de secuencia (Figura 5.15). Pasos necesarios que realiza la aplicación TripPlanner* y que se usa para demostrar el funcionamiento de los productos desarrollados en este PFC (véase Figura 5.16). El proceso comienza cuando la aplicación TripPlanner* tiene que enviar una petición a un proveedor. En primer lugar, TripPlanner* tiene que enviar el mensaje con los datos específicos a I8K (1). I8K recibe el mensaje, lo procesa (codifica) y lo envía de vuelta a TripPlanner* (2).TripPlanner* recibe el mensaje codificado y lo envía al proveedor (3). El proveedor responde a TripPlanner* a través de un mensaje codificado. Luego, con el fin de comprenderlo, TripPlanner* tiene que enviarlo a I8K para decodificar (9). I8K decodifica

87 CAPÍTULO 5. RESULTADOS 65 Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> Proveedor <<system>> TripPlanner* <<system>> I8K 1: encode(mensaje) 1.1: encode 1.2: enviar(mensaje) 2: enviar(mensaje) 2.1: decode(mensaje) 2.1.1: decode 2.1.2: enviar(mensaje) 2.2: generar respuesta 2.3: encode(mensaje) 2.3.1: encode enc, cert 130 enc cert 140 enc cert 130 y : enviar(mensaje) 2.4: enviar(mensaje) Figura 5.15: Protocolo de comunicación para el intercambio de Mensajes de Datos Maestros con niveles de calidad.

88 FASE DE ELABORACIÓN Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) 1-I8K.COD-GE 2-I8K.CODED 7-I8K.CODED 6-I8K.COD-GE / I8K.COD-CR130 / I8K.COD-CR140 /I8K.COD-CR 9-I8K.DEC 10-I8K.DECODED 4-I8K.DEC 5-I8K.DECODED 3-I8K.REQ 8-I8K.RES Figura 5.16: Pasos necesarios para el intercambio de Mensajes de Datos Maestros. el mensaje y lo envía a TripPlanner* (10). TripPlanner* Cuando recibe el mensaje descifrado, lo procesa y realiza las operaciones necesarias. Pasos necesarios que realiza un proveedor de datos (véase Figura 5.16). Cuando el proveedor recibe un mensaje de solicitud de datos de TripPlanner*, el proveedor debe enviar a I8K para decodificar (4). I8K recibe el mensaje, decodifica y la envía de vuelta al proveedor (5). Luego, dependiendo de la información solicitada por TripPlanner*, el proveedor tiene cuatro opciones: - Enviar a I8K el Mensaje de Datos Maestros para que lo codifique(6). I8K codifica y lo envía de vuelta al proveedor (7). - Enviar a I8K para codificar y certificar el mensaje, certificar en la parte, 130 (6). I8K lo codifica y certifica en la parte, 130 y lo envía de vuelta al proveedor (7). - Enviar a I8K para codificar y certificar el mensaje, certificar en la parte, 140 (6). I8K lo codifica y certifica en la parte, 140 y lo envía de vuelta al proveedor (7). - Enviar a I8K para codificar y certificar el mensaje en las partes 130 y 140 (6). I8K lo codifica y certifica en las partes 130 y 140 y se lo reenvía al proveedor(7). Entonces el Proveedor recibe el Mensaje de Datos Maestros codificado/certificado y se lo envía a TripPlanner* (8). Vocabulario de soporte al Protocolo de Comunicación En la sección se ha definido y diseñado el vocabulario que da soporte al Protocolo de Comunicación. Este vocabulario es el que forma la sintaxis formal y da formato a los Mensajes de Datos Maestros. La tecnología que se va a usar para describir el formato de los Mensajes de Datos Maestros es XML; para este fin se ha implementado un esquema de XML para describir la estructura y las restricciones del contenido de los Mensajes de Datos

89 CAPÍTULO 5. RESULTADOS 67 Maestros. La estructura del esquema XML implementado contiene las diferentes partes que forman los Mensajes de Datos Maestros. Estas partes están detalladas en la sección Una primera versión del esquema XML no contemplaba la información referente a las reglas de calidad respecto a las cuales se pueden evaluar los datos; y en la cabecera la parte de la certificación quedaba un poco ambigua (véase Anexo B). Tras realizar un estudio del estándar se mejoró el esquema XML con modificaciones en la cabecera y se añadió la parte referente a las reglas de calidad de datos (véase Anexo C). A continuación en los Listado 5.1, 5.2, 5.3, 5.4, 5.5 y 5.6 se muestran las diferentes partes del Mensaje de Datos Maestros. Cabecera 1 <head> 2 <type-message type="i8k.dec"/> 3 <syntax syntax_version="1.0" syntax_name="classical" syntax_id ="1"/> 4 <cert130 requiredlevelthreshold130="0" certificated130="false" /> 5 <cert140 certifiedmeasuredlevel140="100" requiredlevelthreshold140="50" certificated140="true"/> 6 </head> Listado 5.1: Ejemplo de fragmento correspondiente a la cabecera de un Mensaje de Datos Maestros codificado. Cuerpo 1 <data> 2 <property-value property-ref="01-02# #1"> 3 <controlled-value value-ref="madrid"/> 4 <controlled-value value-ref="londres"/> 5 </property-value> 6 </data> Listado 5.2: Ejemplo de fragmento correspondiente al cuerpo de un Mensaje de Datos Maestros codificado.

90 FASE DE ELABORACIÓN Reglas de calidad de datos 1 <data-quality-rules> 2 <cert130> 3 <set term="01-02# #1" pattern="[]" required="true"/> 4 </cert130> 5 <cert140> 6 <set term="01-02# #1" dqproperty="required"/> 7 </cert140> 8 </data-quality-rules> Listado 5.3: Ejemplo de fragmento correspondiente a las reglas de calidad de un Mensaje de Datos Maestros codificado Información de procedencia 1 <provenance> 2 <provenance-event date=" t23:42: :00" eventtype="encode" organization-ref="i8k" person-ref="tripplanner " person-destination="carsa"/> 3 </provenance> Listado 5.4: Ejemplo de fragmento correspondiente a la información de procedencia (provenance) de un Mensaje de Datos Maestros codificado. Información de certificación de la precisión 1 <accuracy-event xsi:nil="true" xmlns:xsi=" /2001/XMLSchema-instance"/> Listado 5.5: Ejemplo de fragmento correspondiente a la información del nivel de precisión de un Mensaje de Datos Maestros codificado sin certificar el nivel de precisión. Información de certificación de la compleción 1 <completeness-event event-type="certify140" organization-ref=" I8K" date=" t23:49: :00">100 %</completeness -event> Listado 5.6: Ejemplo de fragmento correspondiente a la información del nivel de compleción de un Mensaje de Datos Maestros codificado certificado.

91 CAPÍTULO 5. RESULTADOS 69 Implementación de la base de datos que alberga el Diccionario de Datos Teniendo en cuenta el diseño de la base de datos definido en la iteración anterior se implementa dicha base de datos. El servidor de la base de datos está alojado en una máquina virtual Virtual Box con las siguientes características: Procesador: Procesador doble Núcleo 2Gb de RAM. Sistema Operativo: Windows 2003 Server. Espacio en Disco: 9Gb. 5.3 Fase de construcción La fase de construcción está formada por cinco iteraciones; es la fase más extensa del ciclo de desarrollo de este PFC. En el desarrollo de la iteraciones de esta fase, se realiza el análisis, diseño, implementación y pruebas de cada uno de los grupos funcionales que se identificaron en la fase de Inicio (véase Tabla 4.2) Iteración 4 En esta iteración (véase Tabla 5.5) se aborda el grupo funcional G1-Codificar. En la Figura 5.17 se muestran los diagramas de casos de uso con los casos de uso que forman el Grupo Funcional 1 resaltados en color rojo. Especificación de casos de uso A continuación, los casos de uso que se engloban dentro de este grupo funcional se especifican de manera más detallada, y se describen los escenarios de funcionamiento de cada uno de ellos. ICS-API.CdU1 Definir configuración Descripción: la aplicación establece los parámetros de configuración para ICS-API; para ello debe de suministrar su nombre y el tipo de organización que es (AP para una aplicación cliente que solicita datos a un proveedor; o Provider para un proveedor de datos). Precondición: tener disponible a nivel de aplicación las funcionalidades necesarias.

92 FASE DE CONSTRUCCIÓN Figura 5.17: Diagramas de casos de uso del Grupo Funcional 1. Postcondición: quedan definidos los parámetros de configuración para que ICS-API pueda comunicarse con la Arquitectura de Servicios I8K. Escenario normal: 1. La aplicación especifica a ICS-API el nombre de la organización. 2. La aplicación especifica a ICS-API el tipo de aplicación (AP o Provider). ICS-API.CdU3 Codificar Descripción: una aplicación quiere enviar un Mensaje de Datos Maestros a otra aplicación por lo que tiene que codificar su petición. Este caso de uso se divide: ICS-API.CdU3.1 Añadir términos, ICS-API.CdU3.2 Añadir términos 130 y ICS-API.CdU3.3 Añadir términos 140 Precondición: la aplicación ha definido los parámetros de configuración de ICS-API. Postcondición: la aplicación ha enviado un mensaje a I8K para que sea codificado. Escenario normal: 1. La aplicación identifica los términos que conforman el mensaje que se desea codificar. 2. La aplicación identifica los términos sobre los que se desea evaluar el nivel de precisión (130).

93 CAPÍTULO 5. RESULTADOS La aplicación identifica los términos sobre los que se desea evaluar el nivel de compleción (140). 4. La aplicación, usando ICS-API envía el mensaje a I8K, al agente GestorI8K. Escenario alternativo 1: 1. La aplicación identifica los términos que conforman el mensaje que se desea codificar. 2. La aplicación identifica los términos sobre los que se desea evaluar el nivel de precisión (130). 3. La aplicación, usando ICS-API envía el mensaje a I8K, al agente GestorI8K. Escenario alternativo 2: 1. La aplicación identifica los términos que conforman el mensaje que se desea codificar. 2. La aplicación identifica los términos sobre los que se desea evaluar el nivel de compleción (140). 3. La aplicación, usando ICS-API envía el mensaje a I8K, al agente GestorI8K. Escenario alternativo 3: 1. La aplicación introduce los términos que conforman el mensaje que se desea codificar. 2. La aplicación envía el mensaje a I8K, al agente GestorI8K. GestorI8K.CdU1 Codificar Mensaje Descripción: el agente GestorI8K recibe un Mensaje de Datos Maestros, procesa su cabecera y lo redirige al agente I8K.Cer110. Precondición: una aplicación ha enviado un Mensaje de Datos Maestros a la Arquitectura de Servicios I8K. Postcondición: el Mensaje de Datos Maestros está codificado semánticamente. Escenario normal: 1. La aplicación, usando ICS-API envía un mensaje a I8K, al agente GestorI8K. 2. El GestorI8K recibe un mensaje del tipo I8K.COD-GE, I8K.COD-CR, I8K.COD- CR130 o I8K.COD-CR140 de una aplicación. 3. El GestorI8K envía el mensaje al agente I8K.Cer El agente I8K.Cer110 procesa el mensaje y se lo envía al GestorI8K. 5. El GestorI8K recibe el mensaje del agente I8K.Cer110.

94 FASE DE CONSTRUCCIÓN 6. El GestorI8K envía de vuelta el mensaje codificado de tipo I8K.CODED a la aplicación. I8K.Cer110.CdU1 Codificar Mensaje Descripción: el agente I8K.Cer110, recibe y reenvía un Mensaje de Datos Maestros al agente I8K.110 para que lo codifique. Precondición: el mensaje de datos maestros al agente I8K.Cer110 se lo envia el agente GestorI8K. Postcondición: el mensaje de datos maestros está codificado semánticamente. Escenario normal: 1. El agente I8K.Cer110 recibe un mensaje del GestorI8K del tipo I8K.COD, I8K.COD- CR, I8K.COD-CR130 o I8K.COD-CR El agente I8K.Cer110 envía el mensaje al agente I8K El agente I8K.110 codifica el mensaje y se lo envía al agente I8K.Cer El agente I8K.Cer110 recibe el mensaje codificado del agente I8K El agente I8K.Cer110 envía de vuelta el mensaje codificado al GestorI8K. I8K.110.CdU1 Codificar Mensaje Descripción: el agente I8K.110 tiene la responsabilidad funcional de codificar semánticamente un Mensaje de Datos Maestros. Es decir, recorre todos los términos contenidos en el mensaje y sustituye su nombre por el identificador correspondiente que se encuentra en el Diccionario de Datos. Precondición: el agente I8K.Cer110 le envía a I8K.110 un Mensaje de Datos Maestros. Postcondición: el Mensaje de Datos Maestros está codificado semánticamente. Escenario normal: 1. El agente I8K.Cer110 envíe un mensaje al agente I8K El agente I8K.110 recibe un mensaje del agente I8K.Cer El agente I8K.110 codifica los términos. La codificación la realiza recorriendo uno a uno los términos contenidos en el mensaje, consulta en el Diccionario de Datos el valor de su identificador y sustituye este identificador por el término en el mensaje. 4. El agente I8K.110 envía de vuelta el mensaje al agente I8K.Cer110. Escenario alternativo 1:

95 CAPÍTULO 5. RESULTADOS El agente I8K.Cer110 envíe un mensaje al agente I8K El agente I8K.110 recibe un mensaje del agente I8K.Cer El agente I8K.110 codifica términos y alguno de ellos no existe en el DD. 4. El agente I8K.110 envía de vuelta el mensaje informando del error al agente I8K.Cer110. Escenario alternativo 2: 1. El agente I8K.Cer110 envíe un mensaje al agente I8K El agente I8K.110 recibe un mensaje del agente I8K.Cer El agente I8K.110 detecta que el mensaje no cumple la sintaxis formal. 4. El agente I8K.110 envía de vuelta el mensaje informando del error al agente I8K.Cer110. I8K.110.CdU3 Comprobar Mensaje correcto sintácticamente. Descripción: cuando el agente I8K.110 recibe un mensaje se comprueba si éste cumple con la sintaxis, es decir, cumple el esquema XML definido para los mensajes que se intercambian entre las aplicaciones e I8K. Precondición: que el agente I8K.Cer110 haya enviado un mensaje a codificar. Postcondición: el mensaje es correcto sintácticamente. Escenario normal: 1. El agente I8K.Cer110 envía un mensaje al agente I8K El agente I8K.110 comprueba que el mensaje cumple la sintaxis formal. Escenario alternativo 1: 1. El agente I8K.Cer110 envía un mensaje al agente I8K El agente I8K.110 comprueba que el mensaje no cumple la sintaxis formal. 3. El agente I8K.110 devuelve un mensaje informando del error al agente I8K.Cer110. Diseño e implementación Una vez se ha realizado el análisis de los casos de uso se ha llevado a cabo una identificación de los objetos de dominio que intervienen; se modela el funcionamiento de los casos de uso que componen este grupo funcional con diagramas de secuencia de diseño. Un aspecto a destacar de los diagrama de secuencia es que como este PFC es un desarrollo multisistema, los

96 FASE DE CONSTRUCCIÓN Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) mdqmanager : MDQManager builtxml : BuiltXML Usuario 1: configurar organizacion (nombre, tipo) <<system>> I8K 2: añadir termino (termino) 3: añadir termino 130 (termino) 4: añadir termino 140 (termino) 4.1: crear mensaje 5: crear mensaje 6: devuelve mensaje 4.2: encode(mensaje) 8.1: devuelve mensaje 8: devuelve mensaje 7: codificar mensaje Figura 5.18: Diagrama de secuencia de codificar un mensaje desde ICS-API. diagramas de secuencia están orientados para modelar la interacción entre los objetos de los diferentes sistemas. También se muestran los diagramas de clases de diseño más significativos. ICS-API En la Figura 5.20 se muestra el diagrama de secuencia para definir los parámetros de configuración de ICS-API y codificar un mensaje. Si el usuario es TripPlanner* puede identificar los términos para los que quiere una certificación del nivel de precisión y del nivel de compleción de los datos contenidos en el mensaje; sin embargo si el usuario es un proveedor de datos solo puede añadir términos. En la Figura 5.19 se muestra el diagrama de clases de ICS-API correspondiente a la configuración de parámetros de ICS-API y para codificar un Mensaje de Datos Maestros. El paquete uclm.i8k.mdqmanager agrupa las clases de ICS-API para esta configurar ICS- API y codificar un mensaje. La clase BuiltXML es la encargada de crear el mensaje que se enviará a I8K. Para ello hace uso del paquete uclm.i8k.classjaxb que contiene las clases necesarias para el procesamiento de los Mensajes de Datos Maestros, que están en formato XML. Este paquete se genera con el framework JAXB (véase Capítulo 3). La clase DataMDQ es la que se utiliza para la configuración de ICS-API. Por último la clase MDQManager es la que tiene toda la funcionalidad y es la que se comunica con I8K. Las aplicaciones que utilicen ICS-API sólo tienen acceso a dicha clase.

97 CAPÍTULO 5. RESULTADOS 75 Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) uclm.i8k.mdqmanager.types uclm.i8k.classjaxb organization Organization -name : string 1 type -value <<Enum>> OrganizationType DataMDQ +loadconfiguration() : void +addprovenance(message : string) : void +modifytypemessage(message : string,... uclm.i8k.mdqmanager uclm.i8k.mdqmanager.ws CallGestorI8KWS +encodeandcertificated(message : string) : string configuration Syntax BuiltXML Configuration -typemessage : string -termversion : string -destination : string syntax -idsyntax : long -version : double -name : string -url_xsd : string 1 +builtxml(settermsandvalues, settermsrequired, maptermspattern, maptermssource) : string 1 MDQManager -maptermandvalues -maptermspatterns -maptermssource i8k.ws.client +encodeandcertificated() : string TermTuple -term : string -organization : string term 1 Pair -value : Object settermsandvalues 1..* settermsrequired 1..* +addtermandvalue(term : string, value : Object) : void +addtermsrequired(term : string, required : boolean) : void +addtermpattern(term : string, pattern : string, required : boolean) : void +addtermsource(term : string, source : string, required : boolean) : void +configureorganization(nameorganization : string, type : OrganizationType) : void +setdestination(nameorganization : string) : void Figura 5.19: Diagrama de clases ICS-API. En ICS-API se define un término para poder definir los Datos Maestros que van contenidos en un Mensaje de Datos Maestros. Un término tiene un nombre y una organización, además el término tiene asociado un valor. Este valor puede ser un único valor o una lista de valores, por ejemplo el término Destino de la organización FlightSA puede tener como valor "Madrid"ó "Madrid y Londres". Para representar esta información en la clase MDQManager se utiliza el objeto Pair que está formato por un objeto TermTuple y un value de tipo Object (por ejemplo, un String con valor Londres). El objeto TermTuple está formado por el nombre del término y la organización propietaria de éste. El paquete i8k.ws.client contiene las clases auto generadas que hacen posible la comunicación con los WS que ofrece I8K. Estas clases son accedidas desde una clase, CallGestorI8KWS que implementa la funcionalidad necesaria para ello. I8K En la Figura 5.20 se muestra el diagrama de secuencia correspondiente a los casos de uso de I8K. Se puede observar el paso del mensaje entre los diferentes agentes. En la Figura 5.21 se muestra el diagrama de clases correspondiente al agente I8K.110. Aspectos a destacar sobre el diagrama son: Se ha creado un paquete denominado agi8k110 que agrupa las clases FacadeI8K110 y EncodeI8K110. La primera hace de fachada para cuando se cree el WS; y la segunda contiene el método encode110 que es el encargado de codificar el mensaje y el método addprovenance que actualiza la información sobre el ciclo de vida del mensaje. El método encode recibe un mensaje, primero comprueba qué organización es la que lo envía. Segundo, con la organización recorre término a término y consulta en el DD el identificador del término, sustituye en el mensaje el término por su identificador. Finalmente

98 FASE DE CONSTRUCCIÓN Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> Aplicación 1: encode(mensaje) <<system>> gestori8k <<system>> i8kcer.110 <<system>> i8k.110 DD 1.1: gestiona mensaje 1.2: encode(mensaje) 1.2.1: gestiona mensaje 1.2.2: encode(mensaje) 2: consulta terminos 3: devuelve identificadores 4: codifica mensaje 1.3: devuelve mensaje 5.1: devuelve mensaje 5: devuelve mensaje Figura 5.20: Diagrama de secuencia de codificar un mensaje en I8K. si existen reglas de calidad codifica los términos de éstas. El paquete types agrupa los objetos de dominio persistentes y los objetos de dominio necesarios para modelar la funcionalidad. Los términos de dominio se representan por la clase TermTuple y son definidos por un nombre identificativo y el nombre de la organización a la pertenecen. El paquete classjaxb es un paquete que se auto genera. Contiene las clases necesarias para el procesamiento de los Mensajes de Datos Maestros, que están en formato XML. Este paquete se genera con el framework JAXB (véase Capítulo 3). El caso de uso I8K.110.CdU3 Comprobar Mensaje correcto sintácticamente al utilizar el framework JAXB, queda implementado. Esto es debido a que cada vez que se recibe un Mensaje de Datos Maestros para procesarlo, es necesario deserializarlo (unmarshalling) para convertirlo en un objeto. Y luego, cuando se vuelve a enviar hay serializarlo (marshalling) para convertirlo en un fichero XML. Una vez que los agentes I8K.110, I8K.Cer110 y el GestorI8K tienen su funcionalidad implementada, se realiza la creación de los Servicios Web (en inglés Web Services (WS)) y su posterior publicación respectivamente. El resultado de la implementación de I8K.110 es un WS que ofrece la funcionalidad de codificar un Mensaje de Datos Maestros, y como parte de su procesamiento, I8K.Cer110 consumirá los servicios que I8K.110 le proporciona, y a su vez la implementación de I8K.Cer110 es otro WS que consumirá el GestorI8K. Finalmente la implementación del GestorI8K es otro WS que consumirán las aplicaciones.

99 CAPÍTULO 5. RESULTADOS 77 Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) -instance -sessionfactory TermDao +read(t : Term) : Term +read(id : String) : Term +readterm(t : Term) : Term +create(t : Term) : long +update(t : Term) : boolean +delete(parameter : Term) : void <<framework>> persistence HibernateAgent +getinstance() : HibernateAgent +saveorupdate(o : Object, obj : Object) : Seriealizable +save(o : Object) +delete(obj : Object) OrganizationDao +read(s : Organization) : Organization +create(s : Organization) : long +upade(s : Organization) : boolean +delete(s : Organization) : void 0..* {unique} termterm 0..* {unique} termtermid2 -syntaxid : int -name : String -version : String -url_xsd : String <<ORM Persistable>> Status -statusid : int -value : String <<ORM Persistable>> Syntax status 1 {unique} 0..* {unique} <<ORM Persistable>> Term -termid : String -term : String -identifierid : String -organizationname : String term term 0..* {unique} {unique} {unique} 0..* {unique} term 0..* {unique} term types definition 0..* {unique} status 1 {unique} Configuration -typemessge : string -termversion : string -destination : string <<ORM Persistable>> Definition -definitionid : String -description : String -externalreference : String -organizationname : String definition 0..* {unique} definition 1 {unique} language 1 {unique} language <<ORM Persistable>> Language -languageid : String -value : String 0..1 {unique} organization 1 {unique} {unique} 0..* {unique} definition {unique} organization 0..1 {unique} <<ORM Persistable>> Organization -organizationid : String -name : String -phonenumber : Long -address : String - String -description : String agi8k110 FacadeI8K110 +encode110(message : string) : string EncodeAgI8K110 +encode110(message : string) : string -addprovenance(message) : void classjaxb Figura 5.21: Diagrama de clases del agente I8K.110. Para implementar los distintos servicios se ha tomado la decisión de utilizar Axis2 (véase Capítulo 4, sección 4.2). Para crear los WS con Axis2 hay que configurar el archivo services.xml. Este archivo define el servicio en sí mismo y vincula las clases java que tienen la funcionalidad a él. El Listado 5.7 muestra el fichero services.xml que define el WS del agente I8K <?xml version="1.0" encoding="utf-8"?> 2 <service> 3 <description> 4 Servicio Web para la codificacion y decodificacion de Mensaje de Datos Maestros 5 </description> 6 <messagereceivers> 7 <messagereceiver mep=" 8 class="org.apache.axis2.rpc.receivers.rpcmessagereceiver" /> 9 </messagereceivers> 10 <parameter name="servicetccl">composite</parameter> 11 <parameter name="serviceclass">agi8k110.facadei8k110</ parameter> 12 <operation name="encode110" mep="

100 FASE DE CONSTRUCCIÓN 13 </service> wsdl/in-out" /> Listado 5.7: Ejemplo de archivo service.xml del agente I8K.110. Pruebas Las pruebas realizadas en esta iteración se han centrado en probar toda la funcionalidad que tiene el Grupo Funcional 1 (GP1-Codificar). Se han desarrollado casos de prueba para comprobar que la comunicación entre los diferentes agentes que forman las Arquitectura de Servicios I8K es correcta; para comprobar que la comunicación de ICS-API con la Arquitectura de Servicios I8K es correcta, así como para comprobar que se codifican semánticamente los términos del mensaje. En la Figura 5.22 se muestra una captura de pantalla del resultado de la ejecución de la pruebas con JUnit integrado con Maven, se observa que no se han producido fallos. Figura 5.22: Test Suite para codificar un mensaje Iteración 5 En esta iteración (véase Tabla 5.6) se aborda el grupo funcional G2-Decodificar. En la Figura 5.23 se muestran los diagramas de casos de uso con los casos de uso que forman el Grupo Funcional 2 resaltados en color rojo.

101 CAPÍTULO 5. RESULTADOS 79 Figura 5.23: Diagramas de casos de uso del Grupo Funcional 2. Especificación de casos de uso Los casos de uso que se engloban dentro de este grupo funcional se especifican de manera más detallada, a continuación, se describen los escenarios de funcionamiento de cada uno de ellos. ICS-API.CdU 4 Decodificar Descripción: una aplicación ha recibido un Mensaje de Datos Maestros codificado y para poder entender su contenido, tiene que enviar el Mensaje de Datos Maestros para que se decodifique. Precondición: si el actor es TripPlanner* tiene que haber enviado un mensaje de petición previamente. Si el actor es un proveedor tiene que haber recibido una petición de TripPlanner*. Postcondición: la aplicación ha recibido un mensaje que está decodificado. Escenario normal: 1. La aplicación recibe un mensaje codificado de otra aplicación. 2. La aplicación envía el mensaje a I8K para decodificarlo. 3. I8K procesa y decodifica el mensaje y lo envía a la aplicación. 4. La aplicación recibe un mensaje decodificado de I8K.

102 FASE DE CONSTRUCCIÓN Escenario alternativo 1: 1. La aplicación recibe un mensaje codificado de otra aplicación. 2. La aplicación envía el mensaje a I8K para decodificarlo. 3. I8K procesa el mensaje y éste no es correcto semánticamente. 4. I8K envía de vuelta un mensaje de error. 5. La aplicación recibe un mensaje de I8K, informándole del error. GestorI8K.CdU1 Gestionar Mensajes Descripción: el agente GestorI8K recibe un Mensaje de Datos Maestros; procesa el mensaje para según el tipo de mensaje enviarlo a un agente u otro. Los tipos de mensajes que puede recibir el GestorI8K pueden consultarse en la Tabla Precondición: una aplicación ha enviado un Mensaje de Datos Maestros a la Arquitectura I8K. Postcondición: el mensaje ha sido decodificado semánticamente. Escenario normal: 1. El GestorI8K recibe un mensaje de una aplicación. 2. El GestorI8K procesa el mensaje para conocer su tipo de mensaje. 3. El GestorI8K envía el mensaje al agente correspondiente. 4. El agente recibe el mensaje del agente al que se lo haya enviado previamente. 5. El GestorI8K devuelve un mensaje a la aplicación. Escenario alternativo 1: 1. El GestorI8K recibe un mensaje de una aplicación. 2. El GestorI8K procesa el mensaje para conocer su tipo de mensaje, pero no es un tipo de mensaje válido. 3. El GestorI8K devuelve un mensaje de error a la aplicación. GestorI8K.CdU3 Decodificar Mensaje Descripción: el agente GestorI8K recibe un Mensaje de Datos Maestros procesa su cabecera y lo redirige al agente I8K.Cer110. Precondición: una aplicación ha enviado un Mensaje de Datos Maestros codificado a la Arquitectura de Servicios I8K.

103 CAPÍTULO 5. RESULTADOS 81 Postcondición: el Mensaje de Datos Maestros está decodificado semánticamente. Escenario normal: 1. El GestorI8K recibe un mensaje del tipo I8K.DEC de una aplicación. 2. El GestorI8K envía el mensaje al agente I8K.Cer El agente I8K.Cer110 procesa el mensaje y lo envía de vuelta al GestorI8K. 4. El GestorI8K recibe el mensaje del agente I8K.Cer El GestorI8K devuelve el mensaje decodificado de tipo I8K.DECODED a la aplicación. I8K.Cer110.CdU2 Decodificar Mensaje Descripción: agente I8K.Cer110, recibe y reenvía un Mensaje de Datos Maestros al agente I8K.110 para que lo decodifique. Precondición: el mensaje de datos maestros al agente I8K.Cer110 se lo envia el agente GestorI8K. Postcondición: el Mensaje de Datos Maestros está decodificado semánticamente. Escenario normal: 1. El agente I8K.Cer110 recibe un mensaje del GestorI8K del tipo I8K.DEC. 2. El agente I8K.Cer110 envía el mensaje al agente I8K El agente I8K.110 decodifica el mensaje y se lo envía al agente I8K.Cer El agente I8K.Cer110 recibe el mensaje decodificado del agente I8K El agente I8K.Cer110 devuelve el mensaje decodificado al GestorI8K. I8K.110.CdU2 Decodificar Mensaje Descripción: el agente I8K.110 tiene la responsabilidad funcional de decodificar semánticamente un Mensaje de Datos Maestros. Es decir, recorre todos los identificadores contenidos en un mensaje y los sustituye por el nombre del término correspondiente que se encuentra en el Diccionario de Datos. Precondición: el agente I8K.Cer110 le envía a I8K.110 un Mensaje de Datos Maestros. Postcondición: el Mensaje de Datos Maestros está decodificado semánticamente. Escenario normal: 1. El agente I8K.Cer110 envía un mensaje al agente I8K.Cer El agente I8K.110 recibe un mensaje del agente I8K.Cer110.

104 FASE DE CONSTRUCCIÓN 3. El agente I8K.110 decodifica los términos. La decodificación la realiza recorriendo uno a uno los identificadores contenidos en el mensaje, consulta en el Diccionario de Datos el valor de su término y sustituye este término por el identificador en el mensaje. 4. El agente I8K.110 devuelve el mensaje al agente I8K.Cer110. Escenario alternativo 1: 1. El agente I8K.Cer110 envía un mensaje al agente I8K.Cer El agente I8K.110 recibe un mensaje del agente I8K.Cer El agente I8K.110 decodifica los identificadores y alguno de ellos no existe en el DD. 4. El agente I8K.110 devuelve el mensaje informando del error al agente I8K.Cer110. Escenario alternativo 2: 1. El agente I8K.Cer110 envía un mensaje al agente I8K.Cer El agente I8K.110 recibe un mensaje del agente I8K.Cer El agente I8K.110 detecta que el mensaje no cumple la sintaxis formal. 4. El agente I8K.110 devuelve el mensaje informando del error al agente I8K.Cer110. Diseño e implementación Una vez se han analizado los casos de uso que intervienen en esta iteración se identifican las clases de dominio necesarios para implementar las funcionalidades que se abordan. Se realizan diagramas de secuencia para ver la interacción entre los distintos agentes. ICS-API En la Figura 5.24 se muestra la clase MDQManager, en esta iteración se han implementado varios métodos para llevar a cabo la funcionalidad de decodificar. El método decode es el encargado de decodificar el Mensaje de Datos Maestros. El método privado createmapvalues. Cuando I8K devuelve el mensaje decodificado, se procesa para almacenar todos los términos con sus valores para que las aplicaciones puedan entender el contenido de mensajes y ser capaz de procesar todos los términos. Para acceder a los términos decodificados las aplicaciones utilizan el método getvalue que recibe un término y devuelve el/los valores asociados. Si la aplicación que ha enviado decodificar ha sido un proveedor de datos, hay que procesar las reglas de calidad de datos (términos requeridos por TripPlanner*) para que cuando este

105 CAPÍTULO 5. RESULTADOS 83 Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) -maptermandvalues -maptermspatterns -maptermssource MDQManager +encodeandcertificated() : string +addtermandvalue(term : string, value : Object) : void +addtermsrequired(term : string, required : boolean) : void +addtermpattern(term : string, pattern : string, required : boolean) : void +addtermsource(term : string, source : string, required : boolean) : void +configureorganization(nameorganization : string, type : OrganizationType) : void +setdestination(nameorganization : string) : void +decode(message : string) : void +getvalue(term : string) : Object -createmapvalues(message : string) -processtermsrequired(message_decode : string) : void Figura 5.24: Clase MDQManager de ICS-API. genere su respuesta y se vaya a evaluar y certificar se conozcan dichas reglas establecidas por TripPlanner*. Para ello se utiliza el método privado processtermsrequired. I8K En la Figura 5.25 se muestra el diagrama de secuencia de los casos de uso correspondientes a decodificar un Mensaje de Datos Maestros, en el escenario normal. En el diagrama de clases visto en la iteración anterior solo el paquete que alberga el dominio de negocio se ve modificado, dicho paquete es agi8k110 y se muestra en la Figura Se puede observar una nueva clase llamada DecodeI8K110 que tiene dos métodos. Uno es el método decode110 que es el encargado de decodificar el mensaje y el método addprovenance que implementa la parte 120 del estándar. La clase FacadeI8K110, que sirve para implementar el patrón Fachada, también se ha visto modificada con un nuevo método, decode110. El método decode recibe un mensaje, primero comprueba qué organización es quién lo envía. Segundo, con la organización recorre los identificadores y consulta en el DD el término, sustituye en el mensaje el identificador por su término. Tanto al codificar como al decodificar un mensaje, se tiene en cuenta la organización que envía el mensaje para recuperar o bien, el término o bien el identificador. Esto es debido a que los términos están asociados a una organización concreta, de tal modo que pueden existir dos términos con el mismo nombre pero de organizaciones diferentes y por tanto que signifiquen conceptos diferentes o por el contrario, que términos de diferentes organizaciones que significan lo mismo reciban nombres

106 FASE DE CONSTRUCCIÓN Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> Aplicación 1: decode(mensaje) <<system>> gestori8k <<system>> i8kcer.110 <<system>> i8k.110 DD 1.1: gestiona mensaje 1.2: decode(mensaje) 1.2.1: gestiona mensaje 1.2.2: decode(mensaje) : consulta identificadores : devuelve terminos 1.4: devuelve mensaje 1.3: devuelve mensaje : devuelve mensaje : decodifica mensaje Figura 5.25: Diagrama secuencia de decodificar un mensaje en I8K. Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) agi8k110 FacadeI8K110 +encode110(message : string) : string +decode110(message : string) : string EncodeAgI8K110 +encode110() : string -addprovenance(message) : void DecodeAgI8K110 +decode110(message : string) : string +addprovenance(message) : void I8K110.classJaxb2 Figura 5.26: Paquete del diagrama de clases del agente I8K.110. diferentes. Para solucionar este problema cuando se busca un término o un identificador en el DD se tiene en cuenta la organización. Además existe una tabla en la base de datos donde se almacenan los términos con nombres diferentes de diferentes organizaciones que tienen el mismo significado; este es el mapeo del que se habla en la iteración 2 (véase sección 5.2.2). Finalmente si existen reglas de negocio que encapsulen reglas de calidad de datos, se decodifican los términos de éstas. Pruebas Las pruebas se han centrado en probar toda la funcionalidad que tiene el Grupo Funcional 2 (GP2-Decodificar). De forma similar a las pruebas realizadas en la iteración anterior, se han desarrollado pruebas para comprobar que la comunicación entre los diferentes agentes que forman las Arquitectura de Servicios I8K es correcta; para comprobar que la comunicación

107 CAPÍTULO 5. RESULTADOS 85 de ICS-API con la Arquitectura de Servicios I8K es correcta, así como para comprobar que se decodifican semánticamente los términos del mensaje y se realiza bien el mapeo entre términos de diferentes organizaciones. En la Figura 5.27 se muestra una captura de pantalla del resultado de la ejecución de la pruebas con JUnit integrado con Maven, se observa que no se han producido fallos. Figura 5.27: Test Suite para decodificar un mensaje Iteración 6 En esta iteración (véase Tabla 5.7) se aborda el grupo funcional GF3-Evaluar y certificar en 130. En la Figura 5.28 se muestran los diagramas de casos de uso con los casos de uso que forman el Grupo Funcional 3 resaltados en color rojo. Especificación de casos de uso ICS-API.CdU2 Configurar aspectos de certificación. Descripción: TripPlanner* quiere recibir la respuesta del prooveedor evaluada y certificada. Puede evaluar y certificar el nivel de precisión y compleción o evaluar una de las dos dimensiones de calidad. Precondición: TripPlanner* desea trabajar con datos evaluados y certificados. Postcondición: ICSAPI tiene la información sobre la certificación que desea TripPlanner*. Escenario normal:

108 FASE DE CONSTRUCCIÓN Figura 5.28: Diagramas de casos de uso del Grupo Funcional TripPlanner* indica a ICS-API que desea certificar la respuesta del proveedor en las dimensiones de precisión y de compleción. 2. TripPlanner* indica el nivel mínimo que requiere de precisión. 3. TripPlanner* indica el nivel mínimo que requiere de compleción. Escenario alternativo 1: 1. TripPlanner* indica a ICS-API que desea certificar la respuesta del proveedor en la dimensión de precisión. 2. TripPlanner* indica el nivel mínimo que requiere de precisión. Escenario alternativo 2: 1. TripPlanner* indica a ICS-API que desea certificar la respuesta del proveedor en la dimensión de compleción. 2. TripPlanner* indica el nivel mínimo que requiere de compleción. GestorI8K.CdU3 Certificar en 130 Descripción: el agente GestorI8K recibe un Mensaje de Datos Maestros de un proveedor. El GestorI8K procesa el tipo de mensaje y se lo envia al agente I8K.Cer130. Precondición: TripPlanner* ha especificado que desea evaluar el nivel de precisión del mensaje y que la aplicación que envía codificar sea del tipo Provider.

109 CAPÍTULO 5. RESULTADOS 87 Postcondición: el Mensaje de Datos Maestros ha sido evaluado y certificado. Escenario normal: 1. Un aplicación envía un mensaje para que se certifique el nivel de precisión de sus datos. 2. El GestorI8K recibe un mensaje del tipo I8K.COD-CR130 o I8K.COD-CR de una aplicación. 3. El GestorI8K envía el mensaje al agente I8K.Cer El agente I8K.Cer130 procesa el mensaje y se lo envía de vuelta al GestorI8K. 5. El GestorI8K recibe el mensaje del agente I8K.Cer El GestorI8K devuelve el mensaje certificado y evaluado a la aplicación. I8K.Cer130.CdU1 Evaluar Mensaje en 130 Descripción: el agente I8K.Cer130 recibe un Mensaje de Datos Maestros del agente GestorI8K. De este mensaje tiene que ser evaluado su nivel de la dimensión de calidad de precisión de los datos maestros contenidos en su interior. Para su evaluación tiene que enviar el mensaje al agente I8K.Ev130. Precondición: TripPlanner* ha especificado que desea evaluar el nivel de precisión del mensaje y que la aplicación que envia codificar sea del tipo Provider. Postcondición: los datos maestros contenidos en el mensaje han sido evaluados. Escenario normal: 1. El GestorI8K envía un mensaje a I8K.Cer El agente I8K.Cer130 recibe un mensaje que le ha enviado el GestorI8K. 3. El agente I8K.Cer130 se lo envía al I8K.Ev130 para que lo evalúe. 4. El agente I8K.Ev130 procesa y evalúa el mensaje y se lo envía de vuelta al agente I8K.Cer El agente I8K.Cer130 recibe el mensaje evaluado de I8K.Ev El agente I8K.Cer130 le envía el mensaje de vuelta al GestorI8K. I8K.Ev130.CdU1 Evaluar Mensaje en 130 Descripción: el agente I8K.Ev130 recibe un mensaje del agente I8K.Cer130 para que evalúe el nivel de la dimensión de calidad de precisión de los datos maestros contenidos dentro del mensaje.

110 FASE DE CONSTRUCCIÓN Precondición: el agente I8K.Cer130 ha enviado un mensaje al agente I8K.Ev130. Postcondición: los datos maestros contenidos en el mensaje han sido evaluados. Escenario normal: 1. El agente I8K.Cer130 envía un mensaje al agente I8K.Ev El agente I8K.Ev130 recibe un mensaje del agente I8K.Cer El agente I8K.Ev130 procesa las reglas de calidad especificadas referentes a la precisión (Parte 130 del estándar. Véase Capítulo 3, sección 3.1.3). 4. El agente I8K.Ev130 devuelve el nivel de precisión de los datos maestros contenidos en el mensaje al agente I8K.Cer El agente I8K.Cer130 recibe un mensaje del agente I8K.Ev130. I8K.Cer130.CdU3 Añadir información de certificación 130 Descripción: el agente I8K.Cer130 recibe el nivel de precisión de los datos contenidos en el mensaje. Este nivel se lo envía el agente I8K.Ev130. Ahora con ese valor certifica el mensaje. Precondición: el agente I8K.Ev130 haya evaluado el nivel de precisión de los datos maestros contenidos en el mensaje. Postcondición: el Mensaje de Datos Maestros está evaluado y certificado de acuerdo al nivel de precisión de los datos maestros contenidos en él. Escenario normal: 1. El agente I8K.Cer130 envía un mensaje al agente I8K.Ev El agente I8K.Ev130 procesa y evalúa el mensaje y envía el nivel de precisión de vuelta al agente I8K.Cer El agente I8K.Cer130 recibe el nivel de precisión de los datos contenidos en el mensaje. 4. El agente I8K.Cer130 añade la información de certificación de la precisión. 5. El agente I8K.Cer130 envía de vuelta el mensaje al Gestor I8K. Diseño e implementación Tras realizar la especificación detallada de los casos de uso, se realiza una visión global del trabajo realizado hasta el momento y se identifican las clases de domino que son necesarios para llevar a cabo las funcionalidades que se están desarrollando en esta iteración.

111 CAPÍTULO 5. RESULTADOS 89 ICS-API Respecto al sistema ICS-API se ha añadido un nuevo objeto llamado Certification que va a almacenar la información referente a la certificación de los mensajes. La información es si se desea evaluar y certificar la precisión y/o la compleción, los niveles mínimos requeridos y finalmente los niveles proporcionados una vez que se evalúe el mensaje. En esta iteración se contemplan aspectos para la evaluación y certificación del nivel de compleción aunque su verdadero desarrollo se hará en la iteración anterior. En la clase MDQManager se ha implementado un método, configurecertification, para que TripPlanner* pueda configurar la información referente a los aspectos de certificación; es decir que dimensión de calidad desea que el proveedor evalúe y certifique y cual es el mínimo nivel que requiere. Además se ha añadido otro método, processtermsrequired, para que cuando el proveedor envíe decodificar una petición de TripPlanner* las reglas de calidad definidas por TripPlanner*, no se pierdan y luego se pueda evaluar la respuesta de éste. I8K En la Figura 5.29 se muestra el diagrama de clases correspondiente a la agente I8K.Ev130. Este agente es el encargado de evaluar el nivel de la precisión de los términos, datos maestros, contenidos en el Mensaje de Datos Maestros. El paquete agi8kev130 contiene una única clase, EvaluateAgI8KEv130, que implementa toda la funcionalidad que desempeña dicho agente. El método encargado de evaluar los datos maestros es el método evaluate130. Para evaluar el nivel de precisión se han definido unas reglas de negocio que se aplican a las reglas de calidad de precisión especificadas por TripPlanner* acerca de la precisión que desea en los datos maestros de sus mensajes. TripPlanner* establece un nivel mínimo que requiere en la precisión de sus datos maestros. Además se establecen unas reglas de calidad de datos para la dimensión de precisión. Esta reglas pueden ser de dos tipos: patrón o fuente. En las reglas de tipo patrón se especifica el término, el patrón o expresión regular que tiene que cumplir el valor de dicho término y si es obligatorio que cumpla dicho patrón. Por ejemplo, para el término RETURN_DATE el patrón que debe cumplir su valor viene dado por expresión 1. En las reglas de tipo fuente se especifica el término, una fuente que acredite que el valor es correcto y si es obligatorio que la fuente lo acredite. Por ejemplo, para el término FROM_LOCATION la fuente podría ser una página Web donde estén todas las ciudades del mundo, si el valor de FROM_LOCATION 1 Expresión regular de una fecha ˆ((19 20)dd)-(0?[1-9] 1[012])-(0?[1-9] [12][0-9] 3[01])$

112 FASE DE CONSTRUCCIÓN Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) agi8kev130 EvaluateAgI8KEv130 +evaluate130(message : string) : int +checkaccuracy(message) : int classjaxb Figura 5.29: Diagrama de clases del agente I8K.Ev130. es Madrid la fuente diría que es correcto. Las reglas de negocio consisten en: Si alguno de los términos especificados en las reglas de calidad como obligatorio, bien sea patrón o fuente, no cumple lo especificado el nivel de precisión 0 %. Si todos los términos especificados en las reglas de calidad como obligatorios, tanto de patrón como de fuente, sus valores cumplen lo especificado, el nivel de precisión viene dado por: Nivel precisión = Nivel mínimo establecido por TripPlanner* + (( porcentaje restante * número de términos requeridos no obligatorios) / número de términos requeridos) siendo el porcentaje restante=100- nivel mínimo establecido por TripPlanner* De este modo si ninguno de los valores de los términos contenidos en las reglas de calidad de precisión que sea obligatorio, no cumple la regla, el nivel de precisión del mensaje es nulo. Pero por el contrario si los valores de los términos contenidos en las reglas de calidad de precisión obligatorios cumplen las reglas, el porcentaje de precisión es al menos el establecido por TripPlanner*. Además a este porcentaje se le suma el porcentaje de los valores de los términos contenidos en dichas reglas opcionales que las cumplan. Se garantiza que al menos el nivel de calidad sea el especificado por TripPlanner* Iteración 7 En esta iteración (véase Tabla 5.8) se aborda el grupo funcional GF4-Evaluar y certificar en 140. Este grupo funcional es prácticamente igual que el abordado en la iteración anterior pero difiere en que la dimensión de calidad que se va a evaluar y certificar es la compleción. En la Figura 5.30 se muestran los diagramas de casos de uso con los casos de uso que forman el Grupo Funcional 4 resaltados en color rojo.

113 CAPÍTULO 5. RESULTADOS 91 Figura 5.30: Diagramas de casos de uso del Grupo Funcional 4. Especificación de casos de uso GestorI8K.CdU3 Certificar en 140 Descripción: el agente GestorI8K recibe un Mensaje de Datos Maestros de un proveedor. El GestorI8K procesa el tipo de mensaje y se lo envia al agente I8K.Cer140. Precondición: TripPlanner* ha especificado que desea evaluar el nivel de compleción del mensaje y que la aplicación que envía codificar sea del tipo Provider. Postcondición: el Mensaje de Datos Maestros ha sido evaluado y certificado. Escenario normal: 1. Un aplicación envía un mensaje para que se certifique el nivel de compleción de sus datos. 2. El GestorI8K recibe un mensaje del tipo I8K.COD-CR140 o I8K.COD-CR de una aplicación. 3. El GestorI8K envía el mensaje al agente I8K.Cer El agente I8K.Cer140 procesa el mensaje y se lo envía de vuelta al GestorI8K. 5. El GestorI8K recibe el mensaje del agente I8K.Cer El GestorI8K devuelve el mensaje certificado y evaluado a la aplicación. I8K.Cer140.CdU1 Evaluar Mensaje en 140

114 FASE DE CONSTRUCCIÓN Descripción: el agente I8K.Cer140 recibe un Mensaje de Datos Maestros del agente GestorI8K. De este mensaje tiene que ser evaluado su nivel de la dimensión de calidad de compleción de los datos maestros contenidos en su interior. Para su evaluación tiene que enviar el mensaje al agente I8K.Ev140. Precondición: TripPlanner* ha especificado que desea evaluar el nivel de compleción del mensaje y que la aplicación que envía codificar sea del tipo Provider. Postcondición: los datos maestros contenidos en el mensaje han sido evaluados. Escenario normal: 1. El GestorI8K envía un mensaje a I8K.Cer El agente I8K.Cer130 recibe un mensaje que le ha enviado el GestorI8K. 3. El agente I8K.Cer140 se lo envía al I8K.Ev140 para que lo evalúe. 4. El agente I8K.Ev140 procesa y evalúa el mensaje y se lo envía de vuelta al agente I8K.Cer El agente I8K.Cer140 recibe el mensaje evaluado de I8K.Ev El agente I8K.Cer140 le envía el mensaje de vuelta al GestorI8K. I8K.Ev140.CdU1 Evaluar Mensaje en 140 Descripción: el agente I8K.Ev140 recibe un mensaje del agente I8K.Cer130 para que evalúe el nivel de la dimensión de calidad de compleción de los datos maestros contenidos dentro del mensaje. Precondición: el agente I8K.Cer140 ha enviado un mensaje al agente I8K.Ev140. Postcondición: los datos maestros contenidos en el mensaje han sido evaluados. Escenario normal: 1. El agente I8K.Cer140 envía un mensaje al agente I8K.Ev El agente I8K.Ev140 recibe un mensaje del agente I8K.Cer El agente I8K.Ev140 procesa las reglas de calidad especificadas referentes a la compleción (Parte 140 del estándar. Véase Capítulo 3, sección 3.1.3). 4. El agente I8K.Ev140 devuelve el nivel de compleción de los datos maestros contenidos en el mensaje al agente I8K.Cer El agente I8K.Cer140 recibe un mensaje del agente I8K.Ev130.

115 CAPÍTULO 5. RESULTADOS 93 I8K.Cer140.CdU3 Añadir información de certificación 140 Descripción: el agente I8K.Cer140 recibe el nivel de compleción de los datos contenidos en el mensaje. Este nivel se lo envía el agente I8K.Ev140. Ahora con ese valor certifica el mensaje. Precondición: el agente I8K.Ev140 haya evaluado el nivel de compleción de los datos maestros contenidos en el mensaje. Postcondición: el Mensaje de Datos Maestros está evaluado y certificado de acuerdo al nivel de compleción de los datos maestros contenidos en él. Escenario normal: 1. El agente I8K.Cer140 envía un mensaje al agente I8K.Ev El agente I8K.Ev140 procesa y evalúa el mensaje y envía el nivel de compleción de vuelta al agente I8K.Cer El agente I8K.Cer140 recibe el nivel de compleción de los datos contenidos en el mensaje. 4. El agente I8K.Cer140 añade la información de certificación de la compleción. 5. El agente I8K.Cer140 envía de vuelta el mensaje al Gestor I8K. Diseño e implementación ICS-API En la iteración anterior ya se creó el objeto Certification que representa la información referente a la certificación de los datos maestros contenidos dentro de los Mensaje de Datos Maestros. En esta iteración se terminan de definir los aspectos específicos para implementar la parte referente de certificación del nivel de compleción de los datos. I8K El diagrama de clases correspondiente al agente I8K.Ev140 tiene la misma estructura que el del agente I8K.Ev130. El método encargado de evaluar los datos maestros es el método evaluate140. De manera similar que para evaluar el nivel de precisión, para evaluar el nivel de compleción se han definido otras reglas de negocio que se aplican a las reglas de calidad de compleción especificadas por el TripPlanner* acerca de la compleción que desea en los datos maestros de sus mensajes.

116 FASE DE CONSTRUCCIÓN TripPlanner* establece un nivel mínimo que requiere en la compleción de sus datos maestros. Además establece una reglas de calidad de compleción. En estas reglas se especifica el término y si el valor de dicho término es obligatorio que esté. Por ejemplo la regla que declare que el término FROM_LOCATION es obligatorio indica que su valor debe de tener valor en el mensaje que el proveedor le envie a TripPlanner*. Las reglas de negocio consisten en: Si alguno de los términos especificados en las reglas de calidad de compleción, su valor está vacío el nivel de compleción es 0 %. Si todos los términos especificados en las reglas de calidad, sus valores no están vacíos, el nivel de compleción viene dado por: Nivel compleción = Nivel mínimo establecido por TripPlanner* + (( porcentaje restante * número de términos no vacíos que no estén en las reglas pero que formen el mensaje) / número de términos que no están en las reglas pero forman el mensaje) siendo el porcentaje restante=100- nivel mínimo establecido por TripPlanner* De este modo si ninguno de los valores de los términos contenidos en las reglas de calidad de compleción que sea obligatorio, su valor está vacío, el nivel de compleción del mensaje es nulo. Pero por el contrario si los valores de los términos contenidos en las reglas de calidad de compleción obligatorios tiene valor, el porcentaje de compleción es al menos el establecido por TripPlanner*. Además a este porcentaje se le suma el porcentaje de los valores que no están vacíos de los contenidos en el mensaje. Se garantiza que al menos el nivel de calidad sea el especificado por TripPlanner*. Para que un proveedor de datos certifique su respuesta, que es un Mensaje de Datos Maestros, previamente TripPlanner* debe de haber solicitado la certificación. Cuando el proveedor genera su respuesta, solicita a ICS-API codificar su mensaje para poder enviárselo a TripPlanner*. Internamente ICS-API comprueba si ese mensaje debe ir certificado, si es así modifica el tipo de mensaje a I8K.COD-CR o I8K.COD-CR130 o I8K.COD-CR140 según corresponda (Véase Tabla 5.13). Si no tiene que ir certificado, opera normal y simplemente codifica el mensaje (I8K.COD). Cuando la Arquitectura de Servicios I8K recibe un mensaje, éste llega al GestorI8K quien lo procesa y según el tipo realiza una operativa u otra. -I8K.COD-CR: envía el mensaje I8K.Cer110 para codificarlo, luego se lo envía a I8K.Cer130 para evaluar y certificar el nivel de precisión de los datos y finalmente se lo envía a I8K.Cer140 para evaluar y certificar el nivel de compleción de los datos.

117 CAPÍTULO 5. RESULTADOS 95 Visual Paradigm for UML Enterprise Edition(University of Castilla-La Mancha) <<system>> TripPlanner* 1: enviar(mensaje) <<system>> Proveedor 2: decode(mensaje) <<system>> I8K 2.2: devuelve mensaje 2.1: decodifica mensaje 3: generar respuesta 4: encode(mensaje) alt 4.1: codifica mensaje 4.2: certificar : certificar : certificar : certificar : devuelve mensaje 5: enviar(mensaje) Figura 5.31: Diagrama secuencia del proceso de un proveedor de datos. -I8K.COD-CR130: envía el mensaje I8K.Cer110 para codificarlo y luego se lo envía a I8K.Cer130 para evaluar y certificar el nivel de precisión de los datos. -I8K.COD-CR140: envía el mensaje I8K.Cer110 para codificarlo y luego se lo envía a I8K.Cer140 para evaluar y certificar el nivel de compleción de los datos. En la Figura 5.31 de muestra la secuencia de pasos que un proveedor de datos desde que recibe un mensaje de TripPlanner* hasta que le envía su respuesta. Se observan las alternativas descritas anteriormente Iteración 8 En esta iteración (véase Tabla 5.9) se aborda el grupo funcional GF5-Añadir provenance. En la Figura 5.30 se muestran los diagramas de casos de uso con los casos de uso que forman el Grupo Funcional 5 resaltados en color rojo. Especificación de casos de uso Este grupo funcional contempla los casos de uso:

118 FASE DE CONSTRUCCIÓN Figura 5.32: Diagramas de casos de uso del Grupo Funcional 5. GestorI8K.CdU6 Actualizar provenance. I8K.Cer110.CdU4 Actualizar provenance. I8K.110.CdU4 Actualizar provenance. I8K.Cer130.CdU2 Actulizar provenance. I8K.Ev130.CdU2 Actualizar provenance. I8K.Cer140.CdU2 Actualizar provenance I8K.Ev140.CdU2 Actualizar provenance. Estos casos de uso tiene todos la misma funcionalidad. Descripción: el agente correspondiente añade la al Mensaje de Datos Maestros la información referente al ciclo de vida del mensaje. Precondición: el agente haya recibido y procesado un mensaje. Postcondición: el Mensaje de Datos Maestros contiene la información de procedencia de por donde ha pasado, cuando y que operación se ha realizado en el mensaje. Escenario normal: 1. El agente recibe un mensaje, bien de una aplicación o bien de otro agente.

119 CAPÍTULO 5. RESULTADOS El agente añade la información de en qué agente se encuentra, la operación que va a realizar y fecha y hora. 3. El agente devuelve el mensaje, bien a la aplicación que se lo envió o a un agente. Diseño e implementación Todos los agentes que conforman la arquitectura I8K implementan un método llamado addprovenance. Este método es el encargado de modificar el Mensaje de Datos Maestros incorporando la información del ciclo de vida del mensaje. La información que añaden es el agente que tiene el mensaje en ese momento, la operación que han realizado en el mensaje y el lapso de tiempo en el que se produce dicha acción. 5.4 Fase de transición Esta última fase está formada por tres iteraciones. En ellas se realiza la integración de la Arquitectura de Servicios I8K con ICS-API; a su vez se intregra con la aplicación TripPlanner* y se realizan pruebas de integración y aceptación. Finalmente se prepara toda la documentación y se preparan los productos finales Iteración 9 En esta iteración (véase Tabla 5.10) se aborda: Integración de la Arquitectura de Servicios I8K y de ICS-API. Creación de pruebas de integración. En esta etapa se crea la distribución del sistema ICS-API para ponerlo a disposición del cliente. Para ello se crea el paquete JAR (Java ARchive) ejecutable que se proporcionará a los desarrolladores de las aplicaciones para que puedan utilizar los servicios de I8K. Se ha diseñado e implementado una página web donde se encontrará todo lo necesario para utilizar la Arquitectura de Servicios I8K. En la Figura 5.33 se muestra un prototipo de la interfaz que tendrá dicha Web. Este prototipo se ha realizado con la aplicación Balsamiq Mockups [8]. Es una aplicación para el diseño de borradores o bocetos de interfaces de usuarios. La página Web es

120 FASE DE TRANSICIÓN Figura 5.33: Prototipo de interfaz de la página web Iteración 10 En esta iteración (véase Tabla 5.11) se aborda: Integración de la Arquitectura de Servicios I8K y de ICS-API con la aplicación TripPlanner (TripPlanner*). Prueba final. Se ha realizado la integración de I8K e ICS-API con la aplicación TripPlanner. Se ha comprobado que ICS-API proporciona todos los mecanismos necesarios para ofrecer la comunicación con la Arquitectura de Servicios. Se han realizado dos casos de prueba con JUnit para comprobar el correcto funcionamiento de la aplicación TripPlanner y de los diferentes proveedores con la Arquitectura de Servicios I8K. En la Figura 5.34 se puede observar el resultado de dichas pruebas. En el Anexo E se muestran todos los mensajes que se generan en el proceso entero de intercambio de mensajes. 1. TripPlanner* crea un petición de datos para el proveedor FlightSA, lo envía a codificar. 2. El proveedor recibe el mensaje y lo envía a decodificar para poder entender su contenido. 3. El proveedor crea su respuesta y lo envía a codificar y/o certificar.

121 CAPÍTULO 5. RESULTADOS 99 Figura 5.34: Pruebas realizadas por TripPlanner*. 4. TripPlanner* recibe la respuesta del proveedor y lo envía a decodificar Iteración 11 En esta iteración (véase Tabla 5.12) se aborda: Realización de la documentación el PFC. Realización del manual de usuario. Esta es la última iteración del ciclo, donde se elaboran todos los documentos asociados al PFC: Manual de usuario. Es un documento donde se detallan las funcionalidades de ICS-API, y como utilizarlas para comunicarse con I8K (Véase Anexo F).

122

123 Capítulo 6 Conclusiones y Propuestas En este capítulo se exponen los objetivos logrados con el desarrollo de este PFC y se proponen propuestas de trabajo futuros. Además se incluyen publicaciones sobre el trabajo realizado y una opinión personal. 6.1 Objetivos logrados El objetivo principal del PFC es dar soporte a la implementación del estándar ISO/IEC 8000:2009 partes 100, 102, 110, 120, 130 y 140. Se puede decir que el objetivo ha sido totalmente conseguido con el diseño y construcción de los dos productos descritos a los largo del documento. Los subobjetivos, planteados en el Capítulo 2, cumplidos más importantes han sido: O1. Creación de una Arquitectura de Servicios (I8K) Se ha desarrollado una Arquitectura de Servicios que da soporte a todas las operaciones indicadas en el estándar, desde la codificación y decodificación semántica hasta la acreditación y certificación de los niveles de calidad de datos maestros de los Mensajes de Datos Maestros en el intercambio de estos entre aplicaciones. Para ello se ha desarrollado un multisistema que consta con los agentes necesarios para soportar la especificación del estándar (véase Tabla 4.1). O1.1 Vocabulario de soporte al Protocolo de Comunicación Se ha definido y creado un vocabulario para soportar el protocolo de comunicación de Mensajes de Datos Maestros entre las aplicaciones, TripPlanner* y proveedores, y la Arquitectura

124 OBJETIVOS LOGRADOS de Servicios I8K. En este vocabulario se estructuran los mensajes en las diferentes partes que se han creído necesarias para dar el soporte necesario (véase sección5.2.3). O1.2 Modelo de Datos Maestros para el dominio de TripPlanner* Como se ha elegido un caso de estudio concreto para la realización de este PFC ha sido necesario la creación de un Modelo de Datos Maestros para el dominio específico de la aplicación TripPlanner*. Con este modelo de datos ha sido posible el intercambio de mensajes entre las aplicaciones e I8K (véase sección 5.2.2). O1.3 Definición y creación de un Diccionario de Datos Para llevar a cabo la codificación y decodificación semántica, según establece el estándar, de los Mensajes de Datos Maestros ha sido necesario la creación de un Diccionario de Datos donde se almacenen todos los datos maestros (términos) del dominio específico. Este diccionario almacena toda la información relevante tanto de los términos como de las organizaciones propietarias de ellos (véase sección 5.2.2). O1.4 Definición de un Protocolo de Comunicación entre aplicaciones e I8K Para llevar a cabo el intercambio de mensajes entre las aplicaciones y la Arquitectura de Servicios se ha establecido un Protocolo de Comunicación. Con dicho protocolo se ha monitoreado que dependiendo del tipo de mensaje, la arquitectura realice unas operaciones u otras (véase sección 5.2.3). O1.5 Vocabulario para el intercambio de mensajes Los Mensajes de Datos Maestros tienen que cumplir una sintaxis formal, por lo que para el intercambio se ha desarrollado un vocabulario que de soporte al protocolo y a la sintaxis formal. Se ha utilizado tecnología XML para definir la sintaxis formal, de manera que se ha definido un esquema XML que cumple dicha sintaxis. Todos los mensajes intercambiados tienen que cumplir el esquema XML definido (véase Anexo C) (véase sección 5.2.2). O1.6 Definición de un Protocolo de Comunicación entre agentes Para que los diferentes agentes que conforman I8K puedan comunicarse entre ellos e intercambiando sus mensajes se ha definido un protocolo. Los agentes se comunican a través de

125 CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS 103 Servicios Web. Cada agente ofrece un Servicio Web que desempeña la funcionalidad de dicho agente (véase sección 5.2.3). O1.7 Diseño y creación de un Agente encargado de la codificación y decodificación de mensajes El estándar establece que todos los Mensajes de Datos Maestros que se intercambien entre aplicaciones deben de ir codificados semánticamente. Por ello se ha desarrollado un agente encargado de la codificación y decodificación semántica, el agente I8K.110. Este agente con el Diccionario de Datos codifica y decodifica los términos contenidos en los diferentes mensajes (véase secciones y 5.3.2). O1.8 Diseño y creación de Agentes encargados de la evaluación de las dimensiones de Calidad Para evaluar las dimensiones de calidad de precisión y compleción se han desarrollado dos agentes, I8K.Ev130 e I8K.Ev140. El agente I8K.Ev130 evalúa la precisión de los datos maestros contenidos en los mensajes; y el agente I8K.Ev140 evalúa la compleción. Tanto para evaluar la precisión como la compleción se han diseñado una reglas de negocio que tienen en cuenta las reglas de calidad establecidas por TripPlanner* y evalúan los datos (véase secciones y 5.3.4). O1.9 Diseño y creación de Agentes encargados de la certificación de los mensajes Los Mensaje de Datos Maestros tienen que contener la información sobre la evaluación de las dimensiones de calidad, precisión y compleción de sus datos. Por lo que se han desarrollado dos agentes, I8K.Cer130 e I8K.Cer140, encargados de certificar que los datos contenidos en los mensajes cumplen cierto nivel de calidad. Cada agente certifica una de las dimensiones establecidas en el estándar (véase secciones y 5.3.4). O2. Desarrollo de un API (ICS-API) La Arquitectura de Servicios I8K, por sí sola no se puede utilizar. Por lo que se ha desarrollado un interfaz de programación de aplicaciones, ICS-API, con la que realizar la comunicación desde las aplicaciones con la Arquitectura de Servicios.

126 OBJETIVOS LOGRADOS O2.1 Desarrollo de funcionalidades para la comunicación de aplicaciones con I8K Para establecer la comunicación con I8K es necesario configurar ICS-API para que la comunicación sea correcta. Se han desarrollado las funcionalidades de configuración de la organización, configuración de la certificación y mecanismos para establecer los datos que formarán los Mensajes de Datos Maestros que se desean intercambiar (véase secciones a 5.3.4). O3. Probar los componentes desarrollados con la aplicación TripPlanner Se ha realizado un caso de ejemplo de aplicación con la herramienta TripPlanner* para comprobar que ICS-API proporciona todos los mecanismos necesarios para dar soporte a la comunicación con la Arquitectura de Servicios I8K (véase sección 5.4.2). La Tabla 6.1 muestra un resumen de los objetivos conseguidos Conclusiones Los datos que manejan las organizaciones son un valor muy importante en los procesos de negocio. A pesar de ello, muchas de las organizaciones hoy en día no los tienen en cuenta para lograr ventajas estratégicas. Por tanto, si las organizaciones utilizan datos incorrectos las bases de sus negocios se pueden ver amenazadas. Una forma de solventar las amenazas que pueden producirse debido a datos incorrectos es conociendo el nivel de calidad de los datos con los que se está trabajando. La familia de estándares ISO/IEC 8000: proponen usar un formato preestablecido para el intercambio de datos y los requisitos que deben cumplir dichos mensajes para incorporar información sobre el nivel de calidad de los datos. La implementación de estándares es una de las actividades que se pueden realizar como parte de la Gestión de Datos Maestros. Incorporando por tanto estrategias de Gestión de Datos Maestros se garantiza una organización de los datos donde se rige su calidad, uso y sincronización dentro de las aplicaciones y de los intercambios. La Arquitectura de Servicios I8K proporciona el soporte necesario para evaluar y certificar los datos de acuerdo a los niveles de calidad de precisión y compleción, y proporciona el diccionario de datos necesario para el intercambio de mensajes. También se proporciona ICS- API para llevar a cabo una comunicación con I8K sin necesidad de cambiar las aplicaciones

127 CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS 105 por completo. De esta manera, incorporando ICS-API a los proyectos es posible utilizar I8K. En este PFC además, se presenta un ejemplo de aplicación, TripPlanner, donde se ha utilizado ICS-API para mejorar la aplicación con el fin de contemplar la calidad de los datos. En esta aplicación los datos toman una especial relevancia ya que condicionan el resultado ofrecido a los usuarios. Ahora, gracias a los servicios ofrecidos por la Arquitectura de Servicios I8K puede garantizar que los datos ofrecidos a los usuarios cumplen los niveles de calidad adecuados de precisión y compleción Propuestas de trabajos futuros Durante el desarrollo de este PFC han ido surgiendo nuevas ideas que no se han llevado a cabo debido a que quedaban fuera del alcance del presente proyecto. Las ideas más relevantes son: Realizar una herramienta de mantenimiento para el Diccionario de Datos. Esta herramienta debe permitir la gestión integral de ese Diccionario de Datos abordando temas como añadir, borrar, modificar los términos existentes, gestionar los usuarios que pueden acceder a ellos mediantes servicios web y controlar los mecanismos de pago por acceso. Desarrollar el agente I8K.Mapeo que es el encargado de realizar las conversiones de formato para los datos contenidos en el Mensaje de Datos Maestros desde el formato origen proporcionado por los proveedores al formato genérico de los Datos Maestros. 6.2 Publicaciones Se han preparado dos artículos relacionados con la Arquitectura de Servicios I8K. 1. Bermejo, I., Parody, L., Caballero, I., Gómez-López, M.T. y Gasca, R.M. (2013). Gestión de Calidad de Datos en la Combinación de Actividades dentro del Marco de los Procesos de Negocio. Enviado a las Jornadas de Ingeniería del Software y Bases de Datos (JISBD) Este artículo se centra en gestionar la calidad de datos en la combinación de actividades 2. Parody, L., Bermejo, I., Gómez-López, M.T., Caballero, I., y Gasca, R.M. (2013). Extending Process Aware Information Systems with Data Quality Certification. Enviado

128 OPINIÓN PERSONAL a la Conferencia Internacional sobre Sistemas de Información (ICIS), indexada como Core A por la Asociación Australiana de Investigación y Educación en Computación.. Este artículo propone un extensión del framework PAIS para incluir certificación de calidad de datos 6.3 Opinión personal En lo referente a mi opinión personal sobre el desarrollo del este PFC he de decir que es muy satisfactoria. A lo largo de estos meses de trabajo, mis conocimientos se han visto enriquecidos por el estudio y aprendizaje de todo lo necesario para llevar a cabo el presente PFC. He adquirido nuevos conocimientos tanto teóricos como tecnológicos que complementan mi aprendizaje a lo largo de la carrera. Por último comentar que estoy muy orgullosa del resultado final de este proyecto, pues ahora que se ha concluido se ve la recompensa del esfuerzo y trabajo realizado. Ciudad Real, a 27 de Mayo del 2013 Fdo.: Isabel Bermejo Manzaneque

129 CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS 107 Objetivos Sección Objetivo cumplido O1. Creación de una Arquitectura de Servicios (I8K) 5 O1.1 Modelo de Datos Maestros para el dominio de TripPlanner O1.2 Vocabulario de soporte al Protocolo de Comunicación, modelo de datos maestros específicos para el dominio del TripPlanner (TripPlanner*) y definición del Diccionario de Datos O1.3 Definición y creación de un Diccionario de Datos O1.4 Definición de un Protocolo de Comunicación entre aplicaciones e I8K O1.5 Vocabulario para el intercambio de mensajes O1.6 Definición de un Protocolo de Comunicación entre agentes O1.7 Diseño y creación de un Agente encargado de la y codificación y decodificación de mensajes O1.8 Diseño y creación de Agentes encargados de la y evaluación de las dimensiones de Calidad O1.9 Diseño y creación de Agentes encargados de la y certificación de los mensajes O2 Desarrollo de un API (ICS-API) 5 y O2.1 Desarrollo de funcionalidades para la comunicación a de aplicaciones con I8K O3 Probar los componentes desarrollados con la aplicación 5 y TripPlanner Tabla 6.1: Tabla resumen de los objetivos conseguidos.

130

131 Bibliografía [1] Sitio Web Oficial de Apache Subversion. Accedido el 11 de Mayo de [2] Sitio Web Oficial de Apache Maven. Accedido el 17 de Febrero de [3] Sitio Web Oficial de TexStudio. Accedido el 26 de Mayo de [4] Sitio Web Oficial de Eclipse. Accedido el 20 de Marzo de [5] Sitio Web Oficial de Oracle Corporation. Accedido el 20 de Febrero de [6] Sitio Web Oficial de Apache Software Foundation. Accedido el 26 de Mayo de [7] Sitio Web Oficial de Hibernate. Accedido el 28 de Febrero de [8] Sitio Web Oficial de Balsamiq Mockups. Accedido el 6 de Mayo de [9] A product perspective on total data quality management. communications of the acm 41(2): [10] ISO/DIS : Master Data: Exchange of characteristic data: Overview. ISO/IEC, 2009.

132 110 BIBLIOGRAFÍA [11] ISO/DIS : Master Data: Exchange of characteristic data: Provenance. ISO/IEC, [12] ISO/DIS : Master Data: Exchange of characteristic data: Accuracy. ISO/IEC, [13] ISO/DIS : Master Data: Exchange of characteristic data: Completeness. ISO/IEC, [14] ISO/IEC : Master Data: Exchange of characteristic data: Vocabulary. ISO/IEC, [15] ISO/IEC : Master Data: Exchange of characteristic data: Syntax, semantic encoding, and conformance to data specification. ISO/IEC, [16] BPMN 2.0 by Example. Version 1.0 (non-normative). Object Management Group Standard, [17] 2013, Sitio Web Oficial de W3C. Accedido el 16 de Abril de. [18] Batini, Carlo and Monica Scannapieca: Data Quality: Concepts, Methodologies and Techniques. Springer-Verlag Berlin Heidelberg, [19] Berson, Alex and Larry Dubov: Master Data Management and Data Governance. Mc Graw Hill, [20] Bieberstein, Norbert et al.: Service-Oriented Architecture (SOA) COMPASS: Business Value, Planning, and Enterprise Roadmap. IBM Press, [21] Caballero, Ismael et al.: Iqm3: Information quality management maturity model. J. UCS, 14(22): , [22] Chappell, David and Tyler Jewell: Java Web Services. O Reilly, [23] ECCMA: Electronic Commerce Code Managements Association. [24] Hayler, Andy: Data quality essential to master data management Data-quality-essential-to-master-data-management?%20% utm_medium=em&asrc=em_nlt_ &utm_campaign= _

133 BIBLIOGRAFÍA 111 Data+stewardship+programs+%20%need+solid+plan%2C+firm+ focus_drebernik&utm_source=nlt#.ulaijwidun8. . [25] Huang, Kuant Tsae, Yang W. Lee, and Richar Y. Wang: Quality Information and Knowledge. Upper Saddle River, NJ, USA, Prentice-Hall, [26] Jacobson, Ivar, Grady Booch, and James Rumbaugh: El Proceso Unificado de Desarrollo Software. Addison Wesley, [27] Johnson, Maureen: The DAMA Guide to Data Management Body of Knowledge. Data Management International, [28] Loshin, David: Master Data Management. Elsevier, [29] Loshin, David: The Practitioner s Guide to Data Quality Improvement. Elsevier, [30] McGovern, James et al.: Java Web Services Architecture. Morgan Kaufmann Publishers, [31] Otto, Boris and Andreas Reichert: Organizing master data management: findings from an expert survey. proceedings of the 2010 acm symposium on applied computing [32] Otto, Boris, Andreas Reichert, and Hubert Österle: A reference process model for master data management. [33] Otto, Boris and Alexander Schmidt: Enterprise Master Data Architecture: Design Decision and Options [34] Parody, Luisa, María Teresa Gómez-López, and Rafael M. Gasca: Extending BPMN 2.0 for Modelling thecombination of Activities that involve Data Constraints [35] Parody, Luisa et al.: Improvement of Optimization Agreements in Business Processes involving Web Services. Communications of the IBIMA, 2012, [36] Redman, Thomas C.: Data Quality for the Information Age. Artech House Inc, [37] Redman, Thomas C.: Data Driven: Profiting from Your Most Important Business Asset. Harvard Business Press, 2008.

134 112 BIBLIOGRAFÍA [38] Strong, Diane M., Yang W. Lee, and Richar Y. Wang: Approaches to information quality management: State of the practice of uk asset-intensive organisations. pages 38 46, [39] Strong, Diane M., Yang W. Lee, and Richar Y. Wang: Data quality in context. pages , [40] Vohra, Deepak: Java EE Development with Eclipse. Packt Publishing, [41] Weske, Mathias: Business Process Management: Concepts, Languages, Architectures. Springer, 2007, ISBN [42] Woodall, Philip, Ajith Kumar Parlikad, and Lucas Lebrun: Approaches to Information Quality Management: State of the Practice of UK Asset-Intensive Organisations. Springer London, 2013.

135 Apéndice A Modelo de Datos Maestros para el dominio de la aplicación TripPlanner En este anexo se muestran algunos de los términos que se encuentran en el Diccionario de Datos. En el Cuadro A.1 se muestran los términos de la organización TripPlanner. En el Cuadro A.2 se muestran los términos de la organización FlightSA. Por último en el Cuadro A.3 se muestra el mapeo de términos de estas dos aplicaciones.

136 114 Término Descripción 1 Identificador FROM_LOCATION The city where the user prefers to depart. 0102# #1 TO_LOCATION The city where the user prefers to go. 0102# #1 DEPARTURE_DATE The day when the user prefers to depart. 0102# #1 RETURN_DATE The day when the user prefers to return. 0102# #1 SET_FROM_LOCATION SET_TO_LOCATION The user will not mind walking this distance by car (renting) to go to another airport in the source location. The user will not mind walking this distance by car (renting) to go to another airport in the destination location. 0102# #1 0102# #1 SET_DEPART_DAYS Set of possible departure dates. 0102# #1 SET_RETURN_DAYS Set of possible return dates. 0102# #1 OUTBOUND_FLIGHT Data with the outbound flight. 0102# #1 FROM_LOCATION_FLIGHT City from flight departs. 0102# #1 TO_LOCATION_FLIGHT City where flight arrives. 0102# #1 FROM_AIRPORT Airport from which the flight departs. 0102# #1 TO_AIRPORT Airport to the flight going. 0102# #1 STARTING_DATE Date the flight departs. 0102# #1 ENDING_DATE Date when the flight arrives (can that be transoceanic change the day, but it will be the same date as STARTING_DATE). 0102# #1 DEPARTURE_TIME Departure time (time zone FROM_LOCATION). 0102# #1 ARRIVAL_TIME Flight arrival time (time zone TO_LOCATION). 0102# #1 FLIGHT_NUMBER Flight number. 0102# #1 CARRIER Airline operationg the flight. 0102# #1 FLIGHT_PRICE Flight price. 0102# #1 Cuadro A.1: Datos Maestros de la organización TripPlanner.

137 APÉNDICE A. MODELO DE DATOS MAESTROS PARA EL DOMINIO DE LA APLICACIÓN TRIPPLANNER 115 Término Descripción Identificador FROM_LOCATION The origin, from where you depart. 0102# #1 TO_LOCATION The destination. Where flight. 0102# #1 RETURN_DATE Input data that specify the return date. 0102# #1 SET_FROM_LOCATION Input data, set of possible departure cities. 0102# #1 SET_TO_LOCATION Input data, set of possible destination cities. 0102# #1 ONE_WAY If the flight is a outward (true) or return (false). 0102# #1 SET_DEPARTURE_DATE Input data, set of possible departure dates. 0102# #1 SET_RETURN_DATE Input data, set of possible return dates. 0102# #1 OUTBOUND_FLIGHT Output data that specify the outbound flight. 0102# #1 FROM_AIRPORT Airport from which the flight departs. 0102# #1 TO_AIRPORT Airport to the flight going. 0102# #1 STARTING_DATE Date the flight departs. 0102# #1 ENDING_DATE Date when the flight arrives (can that be transoceanic change the day, but it will be the same date as STARTING_DATE). 0102# #1 DEPARTURE_TIME Departure time (time zone FROM_LOCATION). 0102# #1 ARRIVAL_TIME Flight arrival time (time zone TO_LOCATION) 0102# #1 FLIGHT_NUMBER Número de vuelo Flight number. 0102# #1 CARRIER Airline operating the flight. 0102# #1 FLIGHT_PRICE Flight price. 0102# #1 Cuadro A.2: Datos Maestros de la organización FlightSA.

138 116 Organización Término Identificador Organización Término Identificador TripPlanner FROM_LOCATION_FLIGHT 0102# #1 FlighSA FROM_LOCATION 0102# #1 TO_LOCATION_FLIGHT 0102# #1 TO_LOCATION 0102# #1 FROM_AIRPORT 0102# #1 FROM_AIRPORT 0102# #1 OUTBOUND_FLIGHT 0102# #1 OUTBOUND_FLIGHT 0102# #1 RETURN_DATE 0102# #1 RETURN_DATE 0102# #1 TO_AIRPORT 0102# #1 TO_AIRPORT 0102# #1 STARTING_DATE 0102# #1 STARTING_DATE 0102# #1 ENDING_DATE 0102# #1 ENDING_DATE 0102# #1 DEPARTURE_TIME 0102# #1 DEPARTURE_TIME 0102# #1 ARRIVAL_TIME 0102# #1 ARRIVAL_TIME 0102# #1 FLIGHT_NUMBER 0102# #1 FLIGHT_NUMBER 0102# #1 CARRIER 0102# #1 CARRIER 0102# #1 FLIGHT_PRICE 0102# #1 FLIGHT_PRICE 0102# #1 Cuadro A.3: Mapeo de términos de TripPlanner con FlightSA.

139 Apéndice B Esquema XML del formato de los Mensaje de Datos Maestros. Versión 1 En el Listado B.1 se muestra el esquema XML, versión 1, que tienen que cumplir los Mensajes de Datos Maestros en los intercambios. Esta primera versión no contempla la información referente a las reglas de calidad necesarias para evaluar el nivel de calidad de los datos de acuerdo a la precisión y a la compleción; y la información referente a la certificación que se encuentra en la cabecera quedaba un ambigua. 1 <?xml version="1.0" encoding="utf-8"?> 2 <xs:schema id="xml_e" targetnamespace=" 3 xmlns:mstns=" xmlns=" alarcosj.esi.uclm.es/i8k" 4 xmlns:xs=" xmlns:msdata=" urn:schemas-microsoft-com:xml-msdata" 5 attributeformdefault="qualified" elementformdefault="qualified "> 6 <xs:element name="xml_e" msdata:isdataset="true" 7 msdata:usecurrentlocale="true"> 8 <xs:complextype> 9 <xs:sequence> 10 <xs:element name="head"> 11 <xs:complextype> 12 <xs:sequence> 13 <xs:element name="type-message" minoccurs="1" 14 maxoccurs="1"> 15 <xs:complextype>

140 <xs:attribute name="type" form="unqualified" use="required"> 17 <xs:simpletype> 18 <xs:restriction base="xs:string"> 19 <xs:enumeration value="i8k.cod-ge" /> 20 <xs:enumeration value="i8k.coded" /> 21 <xs:enumeration value="i8k.req" /> 22 <xs:enumeration value="i8k.dec" /> 23 <xs:enumeration value="i8k.decoded" /> 24 <xs:enumeration value="i8k.cod-cr" /> 25 <xs:enumeration value="i8k.cod-cr130" /> 26 <xs:enumeration value="i8k.cod-cr140" /> 27 <xs:enumeration value="i8k.res" /> 28 </xs:restriction> 29 </xs:simpletype> 30 </xs:attribute> 31 </xs:complextype> 32 </xs:element> 33 <xs:element name="syntax" minoccurs="1" maxoccurs= "1"> 34 <xs:complextype> 35 <xs:attribute name="syntax_id" form=" unqualified" 36 type="xs:long" use="required" /> 37 <xs:attribute name="syntax_name" form=" unqualified" 38 type="xs:string" use="required" /> 39 <xs:attribute name="syntax_version" form=" unqualified" 40 type="xs:double" use="required" /> 41 </xs:complextype> 42 </xs:element> 43 <xs:element name="cer130" minoccurs="1" maxoccurs= "1"> 44 <xs:complextype> 45 <xs:attribute name="certificated130" form=" unqualified" 46 type="xs:boolean" use="required" /> 47 <xs:attribute name="level130" form="

141 APÉNDICE B. ESQUEMA XML DEL FORMATO DE LOS MENSAJE DE DATOS MAESTROS. VERSIÓN unqualified" 48 type="xs:long" use="required" /> 49 </xs:complextype> 50 </xs:element> 51 <xs:element name="cer140" minoccurs="1" maxoccurs= "1"> 52 <xs:complextype> 53 <xs:attribute name="certificated140" form=" unqualified" 54 type="xs:boolean" use="required" /> 55 <xs:attribute name="level140" form=" unqualified" 56 type="xs:long" use="required" /> 57 </xs:complextype> 58 </xs:element> 59 </xs:sequence> 60 </xs:complextype> 61 </xs:element> 62 <xs:element name="data"> 63 <xs:complextype> 64 <xs:sequence> 65 <xs:element name="property-value" minoccurs="1" 66 maxoccurs="unbounded"> 67 <xs:complextype> 68 <xs:sequence> 69 <xs:element name="controlled-value" minoccurs="1" 70 maxoccurs="unbounded"> 71 <xs:complextype> 72 <xs:attribute name="value-ref" form=" unqualified" 73 type="xs:string" /> 74 </xs:complextype> 75 </xs:element> 76 </xs:sequence> 77 <xs:attribute name="property-ref" form=" unqualified" 78 type="xs:string" use="required" /> 79 </xs:complextype>

142 </xs:element> 81 </xs:sequence> 82 </xs:complextype> 83 </xs:element> 84 <xs:element name="data-quality"> 85 <xs:complextype> 86 <xs:sequence> 87 <xs:element name="completeness" minoccurs="1" 88 maxoccurs="1"> 89 <xs:complextype> 90 <xs:sequence> 91 <xs:element name="set" minoccurs="0" maxoccurs="unbounded"> 92 <xs:complextype> 93 <xs:attribute name="required" form=" unqualified" 94 type="xs:string" /> 95 </xs:complextype> 96 </xs:element> 97 </xs:sequence> 98 </xs:complextype> 99 </xs:element> 100 </xs:sequence> 101 </xs:complextype> 102 </xs:element> 103 <xs:element name="provenance"> 104 <xs:complextype> 105 <xs:sequence> 106 <xs:element name="provenance-event" minoccurs="1" 107 maxoccurs="unbounded"> 108 <xs:complextype> 109 <xs:attribute name="date" form="unqualified" type="xs:datetime" 110 use="required" /> 111 <xs:attribute name="event-type" form=" unqualified" 112 use="required"> 113 <xs:simpletype> 114 <xs:restriction base="xs:string">

143 APÉNDICE B. ESQUEMA XML DEL FORMATO DE LOS MENSAJE DE DATOS MAESTROS. VERSIÓN <xs:enumeration value="encode" /> 116 <xs:enumeration value="decode" /> 117 <xs:enumeration value="certificate 130" /> 118 <xs:enumeration value="evaluate 130" /> 119 <xs:enumeration value="certificate 140" /> 120 <xs:enumeration value="evaluate 140" /> 121 </xs:restriction> 122 </xs:simpletype> 123 </xs:attribute> 124 <xs:attribute name="organization-ref" form=" unqualified" 125 type="xs:string" use="required" /> 126 <xs:attribute name="person-ref" form=" unqualified" 127 type="xs:string" use="required" /> 128 <xs:attribute name="person-destination" form=" unqualified" 129 type="xs:string" /> 130 </xs:complextype> 131 </xs:element> 132 </xs:sequence> 133 </xs:complextype> 134 </xs:element> 135 <xs:element name="accuracy-event" nillable="true"> 136 <xs:complextype> 137 <xs:simplecontent msdata:columnname="accuracyevent_text"> 138 <xs:extension base="xs:string"> 139 <xs:attribute name="event-type" form=" unqualified" 140 type="xs:string" fixed="evaluation" /> 141 <xs:attribute name="organization-ref" form=" unqualified" 142 type="xs:string" /> 143 <xs:attribute name="date" form="unqualified" 144 </xs:extension> type="xs:datetime" />

144 </xs:simplecontent> 146 </xs:complextype> 147 </xs:element> 148 <xs:element name="completeness-event" nillable="true"> 149 <xs:complextype> 150 <xs:simplecontent msdata:columnname="completenessevent_text"> 151 <xs:extension base="xs:string"> 152 <xs:attribute name="event-type" form=" unqualified" 153 type="xs:string" fixed="evaluation" /> 154 <xs:attribute name="organization-ref" form=" unqualified" 155 type="xs:string" /> 156 <xs:attribute name="date" form="unqualified" type="xs:datetime" /> 157 </xs:extension> 158 </xs:simplecontent> 159 </xs:complextype> 160 </xs:element> 161 </xs:sequence> 162 </xs:complextype> 163 </xs:element> 164 </xs:schema> Listado B.1: Esquema XML. Versión 1

145 Apéndice C Esquema XML del formato de los Mensaje de Datos Maestros. Versión 2 En el Listado C.1 se muestra el esquema XML, versión 2, que tienen que cumplir los Mensajes de Datos Maestros en los intercambios. El esquema XML generado al principio (vã ase Anexo B) no contemplaba los aspectos necesarios para poder certificar y evaluar los Mensajes de Datos Maestros; por lo que fue necesario realizar modificaciones. Esta nueva versión contempla las reglas de calidad necesarias para la evaluación y certificación, y la cabecera se ha modificado. 1 <?xml version="1.0" encoding="utf-8"?> 2 <xs:schema id="xml_e" targetnamespace=" 3 xmlns:mstns=" xmlns=" alarcosj.esi.uclm.es/i8k" 4 xmlns:xs=" xmlns:msdata=" urn:schemas-microsoft-com:xml-msdata" 5 attributeformdefault="qualified" elementformdefault="qualified "> 6 <xs:element name="xml_e" msdata:isdataset="true" 7 msdata:usecurrentlocale="true"> 8 <xs:complextype> 9 <xs:sequence> 10 <xs:element name="head"> 11 <xs:complextype> 12 <xs:sequence> 13 <xs:element name="type-message" minoccurs="1" 14 maxoccurs="1">

146 <xs:complextype> 16 <xs:attribute name="type" form="unqualified" use="required"> 17 <xs:simpletype> 18 <xs:restriction base="xs:string"> 19 <xs:enumeration value="i8k.cod-ge" /> 20 <xs:enumeration value="i8k.coded" /> 21 <xs:enumeration value="i8k.req" /> 22 <xs:enumeration value="i8k.dec" /> 23 <xs:enumeration value="i8k.decoded" /> 24 <xs:enumeration value="i8k.cod-cr" /> 25 <xs:enumeration value="i8k.cod-cr130" /> 26 <xs:enumeration value="i8k.cod-cr140" /> 27 <xs:enumeration value="i8k.res" /> 28 </xs:restriction> 29 </xs:simpletype> 30 </xs:attribute> 31 </xs:complextype> 32 </xs:element> 33 <xs:element name="syntax" minoccurs="1" maxoccurs= "1"> 34 <xs:complextype> 35 <xs:attribute name="syntax_id" form=" unqualified" 36 type="xs:long" use="required" /> 37 <xs:attribute name="syntax_name" form=" unqualified" 38 type="xs:string" use="required" /> 39 <xs:attribute name="syntax_version" form=" unqualified" 40 type="xs:double" use="required" /> 41 </xs:complextype> 42 </xs:element> 43 <xs:element name="cert130" minoccurs="1" maxoccurs ="1"> 44 <xs:complextype> 45 <xs:attribute name="certificated130" form=" unqualified" 46 type="xs:boolean" use="required" />

147 APÉNDICE C. ESQUEMA XML DEL FORMATO DE LOS MENSAJE DE DATOS MAESTROS. VERSIÓN <xs:attribute name="requiredlevelthreshold130" 48 form="unqualified" type="xs:long" use=" required" /> 49 <xs:attribute name="certifiedmeasuredlevel130" 50 form="unqualified" type="xs:long" use=" optional" /> 51 </xs:complextype> 52 </xs:element> 53 <xs:element name="cert140" minoccurs="1" maxoccurs ="1"> 54 <xs:complextype> 55 <xs:attribute name="certificated140" form=" unqualified" 56 type="xs:boolean" use="required" /> 57 <xs:attribute name="requiredlevelthreshold140" 58 form="unqualified" type="xs:long" use=" required" /> 59 <xs:attribute name="certifiedmeasuredlevel140" 60 form="unqualified" type="xs:long" use=" optional" /> 61 </xs:complextype> 62 </xs:element> 63 </xs:sequence> 64 </xs:complextype> 65 </xs:element> 66 <xs:element name="data"> 67 <xs:complextype> 68 <xs:sequence> 69 <xs:element name="property-value" minoccurs="1" 70 maxoccurs="unbounded"> 71 <xs:complextype> 72 <xs:sequence> 73 <xs:element name="controlled-value" minoccurs="1" 74 maxoccurs="unbounded"> 75 <xs:complextype> 76 <xs:attribute name="value-ref" form=" unqualified" 77 type="xs:string" />

148 </xs:complextype> 79 </xs:element> 80 </xs:sequence> 81 <xs:attribute name="property-ref" form=" unqualified" 82 type="xs:string" use="required" /> 83 </xs:complextype> 84 </xs:element> 85 </xs:sequence> 86 </xs:complextype> 87 </xs:element> 88 <xs:element name="data-quality-rules"> 89 <xs:complextype> 90 <xs:sequence> 91 <xs:element name="cert130" minoccurs="1" maxoccurs=" 1"> 92 <xs:complextype> 93 <xs:sequence> 94 <xs:element name="set" minoccurs="0" maxoccurs="unbounded"> 95 <xs:complextype> 96 <xs:attribute name="term" form=" unqualified" 97 type="xs:string" use="required"/> 98 <xs:attribute name="pattern" form=" unqualified" 99 type="xs:string" use="optional"/> 100 <xs:attribute name="source" form=" unqualified" 101 type="xs:string" use="optional"/> 102 <xs:attribute name="required" form=" unqualified" 103 type="xs:string" use="required"/> 104 </xs:complextype> 105 </xs:element> 106 </xs:sequence> 107 </xs:complextype> 108 </xs:element> 109 <xs:element name="cert140" minoccurs="1" maxoccurs

149 APÉNDICE C. ESQUEMA XML DEL FORMATO DE LOS MENSAJE DE DATOS MAESTROS. VERSIÓN ="1"> 110 <xs:complextype> 111 <xs:sequence> 112 <xs:element name="set" minoccurs="0" maxoccurs="unbounded"> 113 <xs:complextype> 114 <xs:attribute name="term" form=" unqualified" 115 type="xs:string" use="required"/> 116 <xs:attribute name="dqproperty" form=" unqualified" 117 type="xs:string" use="required"/> 118 </xs:complextype> 119 </xs:element> 120 </xs:sequence> 121 </xs:complextype> 122 </xs:element> 123 </xs:sequence> 124 </xs:complextype> 125 </xs:element> 126 <xs:element name="provenance"> 127 <xs:complextype> 128 <xs:sequence> 129 <xs:element name="provenance-event" minoccurs="1" 130 maxoccurs="unbounded"> 131 <xs:complextype> 132 <xs:attribute name="date" form="unqualified" type="xs:datetime" 133 use="required" /> 134 <xs:attribute name="event-type" form=" unqualified" 135 use="required"> 136 <xs:simpletype> 137 <xs:restriction base="xs:string"> 138 <xs:enumeration value="encode" /> 139 <xs:enumeration value="decode" /> 140 <xs:enumeration value="certificate 130" /> 141 <xs:enumeration value="evaluate 130" />

150 <xs:enumeration value="certificate 140" /> 143 <xs:enumeration value="evaluate 140" /> 144 </xs:restriction> 145 </xs:simpletype> 146 </xs:attribute> 147 <xs:attribute name="organization-ref" form=" unqualified" 148 type="xs:string" use="required" /> 149 <xs:attribute name="person-ref" form=" unqualified" 150 type="xs:string" use="required" /> 151 <xs:attribute name="person-destination" form=" unqualified" 152 type="xs:string" /> 153 </xs:complextype> 154 </xs:element> 155 </xs:sequence> 156 </xs:complextype> 157 </xs:element> 158 <xs:element name="accuracy-event" nillable="true"> 159 <xs:complextype> 160 <xs:simplecontent msdata:columnname="accuracyevent_text"> 161 <xs:extension base="xs:string"> 162 <xs:attribute name="event-type" form=" unqualified" 163 type="xs:string" fixed="evaluation" /> 164 <xs:attribute name="organization-ref" form=" unqualified" 165 type="xs:string" /> 166 <xs:attribute name="date" form="unqualified" type="xs:datetime" /> 167 </xs:extension> 168 </xs:simplecontent> 169 </xs:complextype> 170 </xs:element> 171 <xs:element name="completeness-event" nillable="true"> 172 <xs:complextype>

151 APÉNDICE C. ESQUEMA XML DEL FORMATO DE LOS MENSAJE DE DATOS MAESTROS. VERSIÓN <xs:simplecontent msdata:columnname="completenessevent_text"> 174 <xs:extension base="xs:string"> 175 <xs:attribute name="event-type" form=" unqualified" 176 type="xs:string" fixed="evaluation" /> 177 <xs:attribute name="organization-ref" form=" unqualified" 178 type="xs:string" /> 179 <xs:attribute name="date" form="unqualified" 180 </xs:extension> type="xs:datetime" /> 181 </xs:simplecontent> 182 </xs:complextype> 183 </xs:element> 184 </xs:sequence> 185 </xs:complextype> 186 </xs:element> 187 </xs:schema> Listado C.1: Esquema XML. Versión 2

152

153 Apéndice D Código de los casos de prueba En el Listado D.1 se muestra la clase creada con JUnit para probar la funcionalidad de codificar un Mensaje de Datos Maestros. Como se tiene acceso al Diccionario de Datos se comprueba que los identificadores del mensaje codificado corresponden con los términos que se indicaron. 1 package test; 2 3 import static org.junit.assert.*; 4 5 import java.io.reader; 6 import java.io.stringreader; 7 8 import javax.xml.bind.jaxbcontext; 9 import javax.xml.bind.jaxbexception; 10 import javax.xml.bind.unmarshaller; import junit.framework.testcase; 13 import junit.framework.testsuite; import org.junit.after; 16 import org.junit.before; 17 import org.junit.test; import uclm.i8k.classjaxb.xmle; 20 import uclm.i8k.mdqmanager.mdqmanager; 21 import uclm.i8k.mdqmanager.types.organizationtype; public class TestCaseEncode extends TestCase { 24

154 public TestCaseEncode(String testname) { 26 super(testname); 27 } public static TestSuite suite() { 30 return new TestSuite(TestCaseEncode.class); 31 } /** 34 * Rigourous Test :-) 35 */ 36 public void testapp() { 37 MDQManager man = new MDQManager(); 38 man.configureorganization("tripplanner", OrganizationType.AP ); 39 man.addtermandvalue("from_location", "Madrid"); 40 man.addtermandvalue("to_location", "Sevilla"); 41 man.addtermandvalue("departure_date", " "); 42 man.setdestination("flightsa"); 43 String message = man.encodeandcertificated(); Reader r = new StringReader(message); 46 JAXBContext jaxbcontext; 47 try { 48 jaxbcontext = JAXBContext.newInstance(XmlE.class); 49 Unmarshaller unmarshaller; 50 unmarshaller = jaxbcontext.createunmarshaller(); // Deserealizamos a partir de un documento XML 53 XmlE xml_message = (XmlE) unmarshaller.unmarshal(r); 54 String idf="01-02# #1"; 55 String idt="01-02# #1"; 56 String idd="01-02# #1"; assertequals(idf, xml_message.getdata().getpropertyvalue().get(2).getpropertyref()); 59 assertequals(idt, xml_message.getdata().getpropertyvalue().get(1).getpropertyref()); 60 assertequals(idd, xml_message.getdata().getpropertyvalue()

155 APÉNDICE D. CÓDIGO DE LOS CASOS DE PRUEBA 133.get(0).getPropertyRef()); 61 } catch (JAXBException e) { 62 e.printstacktrace(); 63 } 64 } } Listado D.1: Test suite para codificar un mensaje. En el Listado D.2 se muestra la clase creada con JUnit para probar la funcionalidad de decodificar un Mensaje de Datos Maestros. Del mismo modo que en caso de prueba de Codificar, se comprueba que los términos del mensaje decodificados corresponden con los identificadores que contenía previamente el mensaje. 1 package test; 2 3 import static org.junit.assert.*; 4 5 import java.io.reader; 6 import java.io.stringreader; 7 8 import javax.xml.bind.jaxbcontext; 9 import javax.xml.bind.jaxbexception; 10 import javax.xml.bind.unmarshaller; import junit.framework.testcase; 13 import junit.framework.testsuite; import org.junit.after; 16 import org.junit.before; 17 import org.junit.test; import uclm.i8k.classjaxb.xmle; 20 import uclm.i8k.mdqmanager.mdqmanager; 21 import uclm.i8k.mdqmanager.types.organizationtype; public class TestCaseDecode extends TestCase { public TestCaseDecode(String testname) {

156 super(testname); 27 } public static TestSuite suite() { 30 return new TestSuite(TestCaseDecode.class); 31 } /** 34 * Rigourous Test :-) 35 */ 36 public void testapp() { 37 MDQManager man = new MDQManager(); 38 man.configureorganization("tripplanner", OrganizationType.AP ); 39 man.addtermandvalue("from_location", "Madrid"); 40 man.addtermandvalue("to_location", "Sevilla"); 41 // man.addtermandvalue("departure_date", " "); 42 man.setdestination("carsa"); 43 String message = man.encodeandcertificated(); man=new MDQManager(); 46 man.configureorganization("carsa", OrganizationType.Provider ); 47 man.decode(message); 48 Reader r = new StringReader(message); 49 JAXBContext jaxbcontext; 50 try { 51 jaxbcontext = JAXBContext.newInstance(XmlE.class); 52 Unmarshaller unmarshaller; 53 unmarshaller = jaxbcontext.createunmarshaller(); // Deserealizamos a partir de un documento XML 56 XmlE xml_message = (XmlE) unmarshaller.unmarshal(r); 57 String idf="pick_up_location"; 58 String idt="drop_off_location"; assertequals("madrid", man.getvalue("pick_up_location")); 61 assertequals("sevilla", man.getvalue("drop_off_location")) ;

157 APÉNDICE D. CÓDIGO DE LOS CASOS DE PRUEBA } catch (JAXBException e) { 64 e.printstacktrace(); 65 } 66 } } Listado D.2: Test suite para decodificar un mensaje.

158

159 Apéndice E Ejemplo de traza del TripPlanner* y el proveedor FlightSA A continuación se muestra la traza de mensajes entre TripPlanner* y el proveedor de ejemplo FlightSA. En el Listado E.1 se muestra un mensaje codificado que ha generado TripPlanner* para enviárselo al proveedor de datos. Se puede observar que TripPlanner* solicita que se evalúe y certifique el nivel de compleción de los datos, y exige un mínimo del 50 %. Este mensaje es del tipo I8K.REQ. 1 <?xml version="1.0" encoding="utf-8" standalone="yes"?> 2 <xml_e xmlns=" 3 <head> 4 <type-message type="i8k.req"/> 5 <syntax syntax_version="1.0" syntax_name="classical" syntax_id ="1"/> 6 <cert130 requiredlevelthreshold130="0" certificated130="false" /> 7 <cert140 requiredlevelthreshold140="50" certificated140="true" /> 8 </head> 9 <data> 10 <property-value property-ref="01-02# #1"> 11 <controlled-value value-ref=" "/> 12 <controlled-value value-ref=" "/> 13 </property-value><property-value property-ref=" 01-02# #1"> 14 <controlled-value value-ref=" "/> 15 <controlled-value value-ref=" "/>

160 <controlled-value value-ref=" "/> 17 </property-value> 18 <property-value property-ref="01-02# #1"> 19 <controlled-value value-ref="londres"/> 20 <controlled-value value-ref="oxford"/> 21 </property-value> 22 <property-value property-ref="01-02# #1"> 23 <controlled-value value-ref="sevilla"/> 24 <controlled-value value-ref="malaga"/> 25 </property-value> 26 <property-value property-ref="01-02# #1"> 27 <controlled-value value-ref=" "/> 28 </property-value> 29 <property-value property-ref="01-02# #1"> 30 <controlled-value value-ref=" "/> 31 </property-value> 32 <property-value property-ref="01-02# #1"> 33 <controlled-value value-ref="londres"/> 34 </property-value> 35 <property-value property-ref="01-02# #1"> 36 <controlled-value value-ref="sevilla"/> 37 </property-value> 38 </data> 39 <data-quality-rules> 40 <cert130/> 41 <cert140> 42 <set term="01-02# #1" dqproperty="required"/> 43 <set term="01-02# #1" dqproperty="required"/> 44 </cert140> 45 </data-quality-rules> 46 <provenance> 47 <provenance-event person-destination="flightsa" person-ref=" TripPlanner" organization-ref="i8k" event-type="encode" date=" t18:26: :00"/> 48 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" /> 49 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26:

161 APÉNDICE E. EJEMPLO DE TRAZA DEL TRIPPLANNER* Y EL PROVEEDOR FLIGHTSA 139 :00"/> 50 <provenance-event person-ref="agi8k110" organization-ref="i8k" > event-type="encode" date=" t18:26: :00"/ 51 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26: :00"/> 52 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" /> 53 </provenance> 54 <accuracy-event xsi:nil="true" xmlns:xsi=" /2001/XMLSchema-instance"/> 55 <completeness-event xsi:nil="true" xmlns:xsi=" 56 </xml_e> /2001/XMLSchema-instance"/> Listado E.1: Mensaje codificado que TripPlanner* ha recibido de I8K y envía a FlightSA.

162 140 El proveedor FlightSA recibido un mensaje de TripPlanner*, para entender su significado tiene que enviarlo a I8K para decodificarlo. En el Listado E.2 se muestra el mensaje decodificado que I8K envía al proveedor. Este mensaje es del tipo I8K.DEC. 1 <?xml version="1.0" encoding="utf-8" standalone="yes"?> 2 <xml_e xmlns=" 3 <head> 4 <type-message type="i8k.dec"/> 5 <syntax syntax_version="1.0" syntax_name="classical" syntax_id ="1"/> 6 <cert130 requiredlevelthreshold130="0" certificated130="false" /> 7 <cert140 requiredlevelthreshold140="50" certificated140="true" /> 8 </head> 9 <data> 10 <property-value property-ref="set_return_date"> 11 <controlled-value value-ref=" "/> 12 <controlled-value value-ref=" "/> 13 </property-value> 14 <property-value property-ref="set_departure_date"> 15 <controlled-value value-ref=" "/> 16 <controlled-value value-ref=" "/> 17 <controlled-value value-ref=" "/> 18 </property-value> 19 <property-value property-ref="set_to_location"> 20 <controlled-value value-ref="londres"/> 21 <controlled-value value-ref="oxford"/> 22 </property-value> 23 <property-value property-ref="set_from_location"> 24 <controlled-value value-ref="sevilla"/> 25 <controlled-value value-ref="malaga"/> 26 </property-value> 27 <property-value property-ref="return_date"> 28 <controlled-value value-ref=" "/> 29 </property-value> 30 <property-value property-ref="departure_date"> 31 <controlled-value value-ref=" "/> 32 </property-value>

163 APÉNDICE E. EJEMPLO DE TRAZA DEL TRIPPLANNER* Y EL PROVEEDOR FLIGHTSA <property-value property-ref="to_location"> 34 <controlled-value value-ref="londres"/> 35 </property-value> 36 <property-value property-ref="from_location"> 37 <controlled-value value-ref="sevilla"/> 38 </property-value> 39 </data> 40 <data-quality-rules> 41 <cert130/> 42 <cert140> 43 <set term="flight_price" dqproperty="required"/> 44 <set term="flight_number" dqproperty="required"/> 45 </cert140> 46 </data-quality-rules> 47 <provenance> 48 <provenance-event person-destination="flightsa" person-ref=" TripPlanner" organization-ref="i8k" event-type="encode" date=" t18:26: :00"/> 49 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" /> 50 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26: :00"/> 51 <provenance-event person-ref="agi8k110" organization-ref="i8k" > event-type="encode" date=" t18:26: :00"/ 52 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26: :00"/> 53 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" /> 54 <provenance-event person-ref="flightsa" organization-ref="i8k" > event-type="decode" date=" t18:27: :00"/ 55 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="decode" date=" t18:26: :00" />

164 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="decode" date=" t18:26: :00"/> 57 <provenance-event person-ref="agi8k110" organization-ref="i8k" event-type="decode" date=" t18:26: :00"/ > 58 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="decode" date=" t18:26: :00"/> 59 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="decode" date=" t18:26: :00" /> 60 </provenance> 61 <accuracy-event xsi:nil="true" xmlns:xsi=" /2001/XMLSchema-instance"/> 62 <completeness-event xsi:nil="true" xmlns:xsi=" /2001/XMLSchema-instance"/></xml_e> Listado E.2: Mensaje decodificado que ha recibido FlightSA de I8K.

165 APÉNDICE E. EJEMPLO DE TRAZA DEL TRIPPLANNER* Y EL PROVEEDOR FLIGHTSA 143 El proveedor FlightSA elabora su respuesta, y tiene que codificar, evaluar y certificar el mensaje que va a enviar a TripPlanner*. En el Listado E.3 se muestra el mensaje codificado que I8K envía al proveedor. El proveedor se lo envá a TripPlanner*. Este mensaje es del tipo I8K.RES. 1 <?xml version="1.0" encoding="utf-8" standalone="yes"?> 2 <xml_e xmlns=" 3 <head> 4 <type-message type="i8k.res"/> 5 <syntax syntax_version="1.0" syntax_name="classical" syntax_id ="1"/> 6 <cert130 requiredlevelthreshold130="0" certificated130="false" /> 7 <cert140 requiredlevelthreshold140="50" certificated140="true" /> 8 </head> 9 <data> 10 <property-value property-ref="01-02# #1"> 11 <controlled-value value-ref="35.0"/> 12 </property-value> 13 <property-value property-ref="01-02# #1"> 14 <controlled-value value-ref="iberia"/> 15 </property-value> 16 <property-value property-ref="01-02# #1"> 17 <controlled-value value-ref="ib25467"/> 18 </property-value> 19 <property-value property-ref="01-02# #1"> 20 <controlled-value value-ref=" h"/> 21 </property-value> 22 <property-value property-ref="01-02# #1"> 23 <controlled-value value-ref=" min"/> 24 </property-value> 25 <property-value property-ref="01-02# #1"> 26 <controlled-value value-ref=" "/> 27 </property-value> 28 <property-value property-ref="01-02# #1"> 29 <controlled-value value-ref=" "/> 30 </property-value> 31 <property-value property-ref="01-02# #1">

166 <controlled-value value-ref="londresairport"/> 33 </property-value> 34 <property-value property-ref="01-02# #1"> 35 <controlled-value value-ref="sevillaairport"/> 36 </property-value> 37 <property-value property-ref="01-02# #1"> 38 <controlled-value value-ref="londres"/> 39 </property-value> 40 <property-value property-ref="01-02# #1"> 41 <controlled-value value-ref="sevilla"/> 42 </property-value> 43 </data> 44 <data-quality-rules> 45 <cert130/> 46 <cert140> 47 <set term="01-02# #1" dqproperty="required"/> 48 <set term="01-02# #1" dqproperty="required"/> 49 </cert140> 50 </data-quality-rules> 51 <provenance> 52 <provenance-event person-destination="flightsa" person-ref=" TripPlanner" organization-ref="i8k" event-type="encode" date=" t18:26: :00"/> 53 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" /> 54 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26: :00"/> 55 <provenance-event person-ref="agi8k110" organization-ref="i8k" event-type="encode" date=" t18:26: :00"/ > 56 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26: :00"/> 57 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" /> 58 <provenance-event person-ref="flightsa" organization-ref="i8k"

167 APÉNDICE E. EJEMPLO DE TRAZA DEL TRIPPLANNER* Y EL PROVEEDOR FLIGHTSA 145 > event-type="decode" date=" t18:27: :00"/ 59 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="decode" date=" t18:26: :00" /> 60 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="decode" date=" t18:26: :00"/> 61 <provenance-event person-ref="agi8k110" organization-ref="i8k" > event-type="decode" date=" t18:26: :00"/ 62 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="decode" date=" t18:26: :00"/> 63 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="decode" date=" t18:26: :00" /> 64 <provenance-event person-destination="tripplanner" person-ref= "FlightSA" organization-ref="i8k" event-type="encode" date =" T18:27: :00"/> 65 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" /> 66 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26: :00"/> 67 <provenance-event person-ref="agi8k110" organization-ref="i8k" > event-type="encode" date=" t18:26: :00"/ 68 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26: :00"/> 69 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" /> 70 </provenance> 71 <accuracy-event xsi:nil="true" xmlns:xsi=" /2001/XMLSchema-instance"/> 72 <completeness-event xsi:nil="true" xmlns:xsi="

168 146 /2001/XMLSchema-instance"/></xml_e> Listado E.3: Mensaje codificado que FlightSA ha recibido de I8K, y va a enviar a TripPlanner*.

169 APÉNDICE E. EJEMPLO DE TRAZA DEL TRIPPLANNER* Y EL PROVEEDOR FLIGHTSA 147 Finalmente TripPlanner* recibe la respuesta del proveedor y necesita decodificarlo para entender su significado, por lo que envía el mensaje a I8K para decodificarlo. En el Listado E.4 se muestra el mensaje decodificado que I8K envía a TripPlanner*. En el mensaje se puede observar el nivel de calidad de compleción que poseen los datos. Este mensaje es del tipo I8K.DEC. 1 <?xml version="1.0" encoding="utf-8" standalone="yes"?> 2 <xml_e xmlns=" 3 <head> 4 <type-message type="i8k.dec"/> 5 <syntax syntax_version="1.0" syntax_name="classical" syntax_id ="1"/> 6 <cert130 requiredlevelthreshold130="0" certificated130="false" /> 7 <cert140 requiredlevelthreshold140="50" certificated140="true" 8 </head> 9 <data> certifiedmeasuredlevel140="100"/> 10 <property-value property-ref="flight_price"> 11 <controlled-value value-ref="35.0"/> 12 </property-value> 13 <property-value property-ref="carrier"> 14 <controlled-value value-ref="iberia"/> 15 </property-value> 16 <property-value property-ref="flight_number"> 17 <controlled-value value-ref="ib25467"/> 18 </property-value> 19 <property-value property-ref="arrival_time"> 20 <controlled-value value-ref=" h"/> 21 </property-value> 22 <property-value property-ref="departure_time"> 23 <controlled-value value-ref=" min"/> 24 </property-value> 25 <property-value property-ref="ending_date"> 26 <controlled-value value-ref=" "/> 27 </property-value> 28 <property-value property-ref="starting_date"> 29 <controlled-value value-ref=" "/> 30 </property-value>

170 <property-value property-ref="to_aiport"> 32 <controlled-value value-ref="londresairport"/> 33 </property-value> 34 <property-value property-ref="from_airport"> 35 <controlled-value value-ref="sevillaairport"/> 36 </property-value> 37 <property-value property-ref="to_location_flight"> 38 <controlled-value value-ref="londres"/> 39 </property-value> 40 <property-value property-ref="from_location_flight"> 41 <controlled-value value-ref="sevilla"/> 42 </property-value> 43 </data> 44 <data-quality-rules> 45 <cert130/> 46 <cert140> 47 <set term="flight_price" dqproperty="required"/> 48 <set term="flight_number" dqproperty="required"/> 49 </cert140> 50 </data-quality-rules> 51 <provenance> 52 <provenance-event person-destination="flightsa" person-ref=" TripPlanner" organization-ref="i8k" event-type="encode" date=" t18:26: :00"/> 53 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" /> 54 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26: :00"/> 55 <provenance-event person-ref="agi8k110" organization-ref="i8k" event-type="encode" date=" t18:26: :00"/ > 56 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26: :00"/> 57 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" />

171 APÉNDICE E. EJEMPLO DE TRAZA DEL TRIPPLANNER* Y EL PROVEEDOR FLIGHTSA <provenance-event person-ref="flightsa" organization-ref="i8k" > event-type="decode" date=" t18:27: :00"/ 59 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="decode" date=" t18:26: :00" /> 60 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="decode" date=" t18:26: :00"/> 61 <provenance-event person-ref="agi8k110" organization-ref="i8k" > event-type="decode" date=" t18:26: :00"/ 62 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="decode" date=" t18:26: :00"/> 63 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="decode" date=" t18:26: :00" /> 64 <provenance-event person-destination="tripplanner" person-ref= "FlightSA" organization-ref="i8k" event-type="encode" date =" T18:27: :00"/> 65 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" /> 66 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26: :00"/> 67 <provenance-event person-ref="agi8k110" organization-ref="i8k" > event-type="encode" date=" t18:26: :00"/ 68 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="encode" date=" t18:26: :00"/> 69 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="encode" date=" t18:26: :00" /> 70 <provenance-event person-ref="tripplanner" organization-ref=" I8K" event-type="decode" date=" t18:27: :00"/>

172 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="decode" date=" t18:26: :00" /> 72 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="decode" date=" t18:26: :00"/> 73 <provenance-event person-ref="agi8k110" organization-ref="i8k" event-type="decode" date=" t18:26: :00"/ > 74 <provenance-event person-ref="agi8kcer110" organization-ref=" I8K" event-type="decode" date=" t18:26: :00"/> 75 <provenance-event person-ref="gestori8k" organization-ref="i8k " event-type="decode" date=" t18:26: :00" /> 76 </provenance> 77 <accuracy-event xsi:nil="true" xmlns:xsi=" /2001/XMLSchema-instance"/> 78 <completeness-event xsi:nil="true" xmlns:xsi=" /2001/XMLSchema-instance"/></xml_e> Listado E.4: Mensaje decodificado que TripPlanner* ha recibido de I8K.

173 Apéndice F Manual de Usuario En el presente anexo se detalla el manual de usuario de la Interfaz de Aplicaciones de Programación ICS-API que proporciona los mecanismos para poder comunicarse con la Arquitectura de Sistemas I8K. Ambos productos desarrollados en el presente PFC. ICS-API puede ser utilizada por dos tipos de aplicaciones: Aplicaciones que desean realizar consultas a proveedores de datos (Tipo de organización AP). Proveedores de datos (Tipo de organización Provider). Para descargarse ICS-API, las aplicaciones tienen que acceder a la dirección Web donde visualizarán la Figura F.1. Figura F.1: Interfaz de la página web. En el enlace ICS-API se descarga el paquete ejecutable ICS-API-1.3.jar. Este ejecutable